[Sip-implementors] Two media type in SDP answer.

[Lorenzo_Boffelli]

Take a look to this scenario!

A UAC sends an INVITE containing SDP like the following:

v=0
o=- 0 0 IN IP4 149.35.48.216
s=SIP Call
c=IN IP4 149.35.48.216
t=0 0
m=audio 5008 RTP/AVP 0 8 4 18
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000

The UAS respond with an OK containing the following SDP:

v=0
o=MxSIP 0 0 IN IP4 149.35.48.175
s=SIP Call
c=IN IP4 149.35.48.175
t=0 0
m=audio 5006 RTP/AVP 0 8
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000

The UAC start to send RTP packet using PCMU codec.
The UAS start to send RTP packet using PCMA codec.

Who are making a mistake?
I think UAS have to respond supporting only one media (PCMU or PCMA).
In this case it receive a SDP offer. In the answer UAS must select one of the
possible codec.
Let me know your opinion!

Thanks
Lorenzo

___________________________________________

Lorenzo Boffelli
STRE Engineer

Allied Telesis K.K.
Head Office / 4F TOC Bldg, 7-22-17 Nishi-Gotanda,
Shinagawa-ku, Tokyo Japan, 141-8635
European R&D Center
Piazza Tirana, 24/4 b Phone: [phone]
20147 Milano Fax: [phone]
ITALY
Email: lorenzo_boffelli at alliedtelesyn.com
___________________________________________

[Nick Hollinghurst]

If UAS supports only one codec at a time, it should pick just one codec in
its answer, e.g. PCMA. But if the UAS supports both codecs and can switch
between them, it is allowed to include both codecs in its answer. Your
example is perfectly correct.

The difficulty is when the UAC supports either codec, but only one at a time.
Some equipment (e.g. Cisco gateways) resolve the problem by sending a *third*
session description in the ACK. This seems to be a perfectly good solution.
It would be convenient if this was allowed. Unfortunately in sip bis-05 it
has been declared a violation of the "offer/answer" model.

I can imagine two things the UAC can do to get around the restriction:

(a) It could start with an OPTIONS to discover what codecs are supported,
then INVITE the UAS, picking just a single codec. [This assumes that
OPTIONS gives an answer consistent with INVITE.]

(b) It could ACK the response then immediately re-INVITE it with just a
single codec. [This delays the call startup, and if the ACK was lost
it could get into an awkward "Retry-After" scenario.]

Neither solution is ideal...

Nick

Post by Lorenzo_Boffelli
Take a look to this scenario!
v=0
o=- 0 0 IN IP4 149.35.48.216
s=SIP Call
c=IN IP4 149.35.48.216
t=0 0
m=audio 5008 RTP/AVP 0 8 4 18
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000
v=0
o=MxSIP 0 0 IN IP4 149.35.48.175
s=SIP Call
c=IN IP4 149.35.48.175
t=0 0
m=audio 5006 RTP/AVP 0 8
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
The UAC start to send RTP packet using PCMU codec.
The UAS start to send RTP packet using PCMA codec.
Who are making a mistake?
I think UAS have to respond supporting only one media (PCMU or PCMA).
In this case it receive a SDP offer. In the answer UAS must select one of the
possible codec.
Let me know your opinion!
Thanks
Lorenzo

[Shen, Eran]

Nick,

What if such equipment (e.g. Cisco gateway) gets INVITE without SDP offer?
This means they have to send 200 (Ok) with SDP Offer and get the SDP Answer
in the ACK and the problem will happen again.

Another way to try and avoid this problem
(which is quite common by the way, this is because many Equipment
manufacturers port to SIP systems that support H.323 and the H.323 solve
that with
the openLogicalChannel model. So you can allow your self to support only one
codec at a time).

Anyway to try to avoid this: Try to always be the SDP answerer and not the
SDP offerer. Meaning always send INVITE with no SDP and answer on ACK.


Thanks,

Eran.

Eran Shen

Intel Corporation
Telecommunications and Embedded Group
P.O Box 58, Migdal Tefen, Israel
Tel: [phone]
<mailto:eran.shen at Intel.Com>




-----Original Message-----
From: njh at uk.research.att.com [mailto:njh at uk.research.att.com]
Sent: Thursday, December 13, 2001 4:56 PM
To: Lorenzo_Boffelli at smtpgwy.alliedtelesyn.com
Cc: sip-implementors at cs.columbia.edu
Subject: Re: [Sip-implementors] Two media type in SDP answer.


If UAS supports only one codec at a time, it should pick just one codec in
its answer, e.g. PCMA. But if the UAS supports both codecs and can switch
between them, it is allowed to include both codecs in its answer. Your
example is perfectly correct.

The difficulty is when the UAC supports either codec, but only one at a
time.
Some equipment (e.g. Cisco gateways) resolve the problem by sending a
*third*
session description in the ACK. This seems to be a perfectly good solution.
It would be convenient if this was allowed. Unfortunately in sip bis-05 it
has been declared a violation of the "offer/answer" model.

I can imagine two things the UAC can do to get around the restriction:

(a) It could start with an OPTIONS to discover what codecs are supported,
then INVITE the UAS, picking just a single codec. [This assumes that
OPTIONS gives an answer consistent with INVITE.]

(b) It could ACK the response then immediately re-INVITE it with just a
single codec. [This delays the call startup, and if the ACK was lost
it could get into an awkward "Retry-After" scenario.]

Neither solution is ideal...

Nick

Post by Lorenzo_Boffelli
Take a look to this scenario!
v=0
o=- 0 0 IN IP4 149.35.48.216
s=SIP Call
c=IN IP4 149.35.48.216
t=0 0
m=audio 5008 RTP/AVP 0 8 4 18
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000
v=0
o=MxSIP 0 0 IN IP4 149.35.48.175
s=SIP Call
c=IN IP4 149.35.48.175
t=0 0
m=audio 5006 RTP/AVP 0 8
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
The UAC start to send RTP packet using PCMU codec.
The UAS start to send RTP packet using PCMA codec.
Who are making a mistake?
I think UAS have to respond supporting only one media (PCMU or PCMA).
In this case it receive a SDP offer. In the answer UAS must select one of

the

Post by Lorenzo_Boffelli
possible codec.
Let me know your opinion!
Thanks
Lorenzo

[Nick Hollinghurst]

Post by Shen, Eran
What if such equipment (e.g. Cisco gateway) gets INVITE without SDP offer?
This means they have to send 200 (Ok) with SDP Offer and get the SDP Answer
in the ACK and the problem will happen again.

...

Post by Shen, Eran
Anyway to try to avoid this: Try to always be the SDP answerer and not the
SDP offerer. Meaning always send INVITE with no SDP and answer on ACK.
Thanks,
Eran.

Oops. Sorry, I forgot about this case -- thanks for pointing it out.

It's still not a complete solution, though: now it puts the pressure on
the UAS. *Somebody* has to make an offer, and for maximal compatibility it
should list as many codecs as it knows about; yet it can't be sure that
the other end will pick only one, because SDP allows it to pick several.

Nick

[David Most]

No. If your UAC has the ability to receive multiple codecs all at once, then by all means send them all in your offer. If you cannot receive multiple codecs, then DO NOT send them!

Solution: send the preferred codec in the offer. If the UAS doesn't support that codec, they'll send "options sdp" in the 4xx (forget which one) response the giving reason they don't support the INVITE as is. The UAC may choose a codec from the response sdp and re-invite.

Post by Nick Hollinghurst
It's still not a complete solution, though: now it puts the pressure on
the UAS. *Somebody* has to make an offer, and for maximal compatibility it
should list as many codecs as it knows about; yet it can't be sure that
the other end will pick only one, because SDP allows it to pick several.