[SIPForum-discussion] Call connected on different codec

Thu Dec 29 22:02:20 UTC 2011

First of all I am sorry for my mistake about 487 (instead 488) - that I rectified after - must have been the vacation mind set.
Anyway, it would be good if everybody would follow the RFCs as it would be good if RFCs would be updated with real life network requirements. I have been working with interworking many SIP applications for 6 years. So, the practice would tell me that as UAC you do not want a 200 ok with another codec than offered in Invite (as mentioned in RFC 3261). You would like to be able to reroute the call over another carrier that supports your codec (eventually use your own transcoding device for these particular calls) based on the UAS release cause.
So the best behaviour is for UAS to release with correct cause - and 488 seems to be implemented by many vendors - although to me it makes more sense to be more specific and use a release cause that would help rerouting the call only for the exact type of failure (as we can see the RFC uses SHOULD use 488 and not MUST).
For the UAC not having to wait for 200 ok and getting 4XX release it means time saved in continuing the call on another route. Plus it is quite hard to reroute based on 200 ok SDP response unless there is a built in mechanism.

Aniella

________________________________
From: Abhishek Jain <mail.abhishekjain at gmail.com>
To: Aniella Juverdeanu
Cc: balajivenkats at gmail.com <balajivenkats at gmail.com>; discussion at sipforum.org <discussion at sipforum.org>
Sent: Thu Dec 29 04:50:42 2011
Subject: Re: [SIPForum-discussion] Call connected on different codec

Please refer the RFC 3261 section 13.2.2.4. This is meant for the UAC behaviour.

"If the offer in the 2xx response is not acceptable, the UAC core MUST generate a valid answer in the ACK and
   then send a BYE immediately."

For UAS behaviour, see the section "13.3.1.3 The INVITE is Rejected". "A UAS rejecting an offer contained in an INVITE SHOULD return a 488 (Not Acceptable Here) response. Such a response SHOULD include a Warning header field value explaining why the offer was rejected."

Regards
Abhishek

On Tue, Dec 27, 2011 at 3:18 AM, Aniella Juverdeanu <Aniella.Juverdeanu at telus.com<mailto:Aniella.Juverdeanu at telus.com>> wrote:
Actually it should be 415 or at worst 488.

________________________________
From: Aniella Juverdeanu
To: 'mail.abhishekjain at gmail.com<mailto:mail.abhishekjain at gmail.com>' <mail.abhishekjain at gmail.com<mailto:mail.abhishekjain at gmail.com>>; 'balajivenkats at gmail.com<mailto:balajivenkats at gmail.com>' <balajivenkats at gmail.com<mailto:balajivenkats at gmail.com>>
Cc: 'discussion at sipforum.org<mailto:discussion at sipforum.org>' <discussion at sipforum.org<mailto:discussion at sipforum.org>>
Sent: Mon Dec 26 14:43:39 2011

Subject: Re: [SIPForum-discussion] Call connected on different codec

Actually the called party has to respond with 4XX for bearer not supported (please check which one applies - it might be 487 - not supported). You cannot just release with no reason. The calling party can then take alternate route or insert a transcoding device and re-Invite with appropiate CODEC.

Aniella

________________________________
From: discussion-bounces at sipforum.org<mailto:discussion-bounces at sipforum.org> <discussion-bounces at sipforum.org<mailto:discussion-bounces at sipforum.org>>
To: balajivenkat subramanian <balajivenkats at gmail.com<mailto:balajivenkats at gmail.com>>
Cc: discussion at sipforum.org<mailto:discussion at sipforum.org> <discussion at sipforum.org<mailto:discussion at sipforum.org>>
Sent: Fri Dec 23 13:23:49 2011
Subject: Re: [SIPForum-discussion] Call connected on different codec

Hi, This is a bug.
Actually, if the offer and answer do not match then the caller must send the ACK and immediately send out BYE. In your case since the caller is not sending out BYE, so this is a BUG.

Regards
Abhishek

On Thu, Dec 22, 2011 at 2:08 PM, mehmet <eng.mehmetozi at gmail.com<mailto:eng.mehmetozi at gmail.com>> wrote:
Hi,

I assume that supplier does not support G723 and ilbc . In this case it can not return with a new challenge, sends an error response instead.

But could you please clarify does supplier support g723 and ilbc?

Regards.

2011/12/21 balajivenkat subramanian <balajivenkats at gmail.com<mailto:balajivenkats at gmail.com>>
Hello Guys ,

Pls share your thoughts whether the below scenario is right behaviour .

Customer  - > Softswitch - > Supplier .

1. Customer invite has codec G723 , ilbc etc .
2.Supplier is responding back with only G711ulaw codec which was not offered by Customer .
3. Call got connected with voice on both sides .

Thanks ,
Venkat

_______________________________________________
This is the SIP Forum discussion mailing list
TO UNSUBSCRIBE, or edit your delivery options, please visit http://sipforum.org/mailman/listinfo/discussion
Post to the list at discussion at sipforum.org<mailto:discussion at sipforum.org>

_______________________________________________
This is the SIP Forum discussion mailing list
TO UNSUBSCRIBE, or edit your delivery options, please visit http://sipforum.org/mailman/listinfo/discussion
Post to the list at discussion at sipforum.org<mailto:discussion at sipforum.org>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20111229/cbb73864/attachment-0002.html>