[SIPForum-discussion] Offer_answer issue
SINGH ANURAG
Anurag.Singh at alcatel-lucent.com
Mon Jun 1 13:02:14 UTC 2009
Hi,
Thanks for the input Tomasz.
If I understood well than I hope you are saying that the UA1 should
send Offer with 8 in media line,
now suppose 200OK still has multiple codec (like 18 8) in answer ...
So my question is that does it seem correct to send INVITE always.
as it could be a unlimited exchange of messages
Your opinion please
Regards
Anurag
________________________________
From: Tomasz Zieleniewski [mailto:tzieleniewski at gmail.com]
Sent: Monday, June 01, 2009 2:16 PM
To: SINGH ANURAG
Cc: discussion at sipforum.org
Subject: Re: [SIPForum-discussion] Offer_answer issue
Hi,
In Your case UA1 should normally construct initial INVITE with SDP offer
containing this particular codec specification. Despite any other
non-media
related reasons UA2 will reject INVITE with 488/606 (Not Acceptable
Here) response
in case the session description is not acceptable or will accept session
offer by
sending a final 2xx response with SDP answer containing the same codec
specification.
Provisional responses can also contain the same SDP contents as final
2xx one.
Kind regards,
Tomasz Zieleniewski
2009/5/29 SINGH ANURAG <Anurag.Singh at alcatel-lucent.com>
Hello All,
UA1 can open cahnnel only with one codec, so it need to negotiate with
one codec
I will take you to the example straight.
UA1 UA2
-----INVITE(Offer m =0 8 18)----------->
<-------200OK(Answer m=18 8)-----------
--------INVITE(offer m=18)------------->
<-------200OK(Answer m=8 18)------------
what should be the behaviour?? is there any standred stating the
behaviour
Regards
Anurag
_______________________________________________
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20090601/6d031a2b/attachment-0002.html>
More information about the discussion
mailing list