[sip-comm-dev] Adding the zrtp-hash SDP attribute - plus some questions


#1

All,

to be even more compliant to ZRTP spec I added the zrtp-hash
attribute to the SDP part of SIP messages. While implementing
and testing this I also looked into the SDP processing of SC.

As far as I can see SC does not process any codec specific
stuff defined in SDP attributes like rtmap, ftmp but
uses fixed strings and mappings. SC seems to use / implement
SDP codec handling that is not compliant to RFCs 2327, 3264,
1890. SC uses codec numbers in the dynamic range without looking
at rtmap etc.

Is this a correct interpretation of the code in CallSessionImpl?

Just for curiosity: the Jain SIP RI library (latest version)
also seems to have some problems with SDP handling. At least
two methods seem "suspicious":

MediaDescription.getMimeTypes(...) and
MediaDescription.getMimeParameters(...)

The description and implementation of these methods somehow
don't map. I'll check that again.

Regards,
Werner

PS: the zrtp-hash attribute does not do any harm to SC SDP
processing :-). I'll do a check-in of CallSessionImpl during
the weekend after some more tests.

Werner

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#2

Hey Werner,

All,

to be even more compliant to ZRTP spec I added the zrtp-hash
attribute to the SDP part of SIP messages.

Great! Looking forward to checking it out.

While implementing
and testing this I also looked into the SDP processing of SC.

As far as I can see SC does not process any codec specific
stuff defined in SDP attributes like rtmap, ftmp but
uses fixed strings and mappings. SC seems to use / implement
SDP codec handling that is not compliant to RFCs 2327, 3264,
1890. SC uses codec numbers in the dynamic range without looking
at rtmap etc.

Is this a correct interpretation of the code in CallSessionImpl?

Mostly yes. There are some occasions on which we do have a look at
rtpmap attributes. One of them is a G.723 attribute that was breaking
codec compatibility and the other is when using H.264 but that's all.

Some day we'd need to get busy completing our parsing procedures.

Just for curiosity: the Jain SIP RI library (latest version)
also seems to have some problems with SDP handling. At least
two methods seem "suspicious":

MediaDescription.getMimeTypes(...) and
MediaDescription.getMimeParameters(...)

The description and implementation of these methods somehow
don't map. I'll check that again.

That's possible since the SDP impl hasn't been receiving that much
attention lately. I saw you post on jain-sip today so you seem to have
also noticed that.

Cheers
Emil

···

On Fri, Jan 30, 2009 at 7:31 PM, Werner Dittmann <Werner.Dittmann@t-online.de> wrote:


#3

Emil,

thanks for the confirmation. Actually I'm looking into the
SDP code and have some ideas already how to improve it. If
nobody else is working on this issue I'll prepare some patches
and make some proposals how to enhance SDP stuff. This could help
SC also in the long run.

But this may take some time because my first prio is the ZRTP
stuff :slight_smile: .

Regards,
Werner

Emil Ivov schrieb:

···

Hey Werner,

On Fri, Jan 30, 2009 at 7:31 PM, Werner Dittmann > <Werner.Dittmann@t-online.de> wrote:

All,

to be even more compliant to ZRTP spec I added the zrtp-hash
attribute to the SDP part of SIP messages.

Great! Looking forward to checking it out.

While implementing
and testing this I also looked into the SDP processing of SC.

As far as I can see SC does not process any codec specific
stuff defined in SDP attributes like rtmap, ftmp but
uses fixed strings and mappings. SC seems to use / implement
SDP codec handling that is not compliant to RFCs 2327, 3264,
1890. SC uses codec numbers in the dynamic range without looking
at rtmap etc.

Is this a correct interpretation of the code in CallSessionImpl?

Mostly yes. There are some occasions on which we do have a look at
rtpmap attributes. One of them is a G.723 attribute that was breaking
codec compatibility and the other is when using H.264 but that's all.

Some day we'd need to get busy completing our parsing procedures.

Just for curiosity: the Jain SIP RI library (latest version)
also seems to have some problems with SDP handling. At least
two methods seem "suspicious":

MediaDescription.getMimeTypes(...) and
MediaDescription.getMimeParameters(...)

The description and implementation of these methods somehow
don't map. I'll check that again.

That's possible since the SDP impl hasn't been receiving that much
attention lately. I saw you post on jain-sip today so you seem to have
also noticed that.

Cheers
Emil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net