[Freeswitch-dev] Handling of multiple 183 responses with different SDP
Michael Jerris
mike at jerris.com
Wed Oct 27 07:26:04 PDT 2010
http://www.ietf.org/rfc/rfc3264.txt
On Oct 27, 2010, at 7:15 AM, Irina Ivanova wrote:
> Hi! We are getting the same problem as described in the jira ticket with
> key FS-715:
> http://jira.freeswitch.org/browse/FS-715?page=com.atlassian.jira.plugin.system.issuetabpanels%3Aall-tabpanel
>
> Our provider is also sending us more than one 183 Session progress
> response, each of them with SDP where destination IP address is the same
> but the UDP ports are different.
>
> If is needed I can provide the pcap file where you can see that after
> receiving of second 183 Session progress response (with updated SDP)
> Freeswitch continues to listen on an old port. As a consequence, no
> audio can be heard.
>
> Our provider assures us that sending of more than one 183 Session
> progress responses is completely standard behavior that does not violate
> SIP RFC 3261 and is handled correctly by any ATA VoIP.
> We verified the Asterisk behavior in this case, and can say that it
> handles receiving of multiple 183 Session progress responses without any
> problems and changes the UDP port each time it gets changed in session
> description inside of 183 response.
>
> Our provider gave us a reference to SIP RFC 3261:
>
> 13 Initiating a Session
> 13.1 Overview
> "Before sending a final response, the UAS can also send provisional
> responses (1xx) to advise the UAC of progress in contacting the called user.
> After possibly receiving one or more provisional responses, the UAC will
> get one or more 2xx responses or one non-2xx final response."
>
> "one or more provisional responses" was underlined by our provider and
> in addition to this was said that there is no any place in RFC from
> which you can conclude that you can not send more than one SIP 183
> Session Progress response.
>
> We also found a document regarding 183 response:
> http://tools.ietf.org/html/draft-ietf-sip-183-00
>
> Here are some references to the parts talking about temporary media and
> session description change:
>
> 4.2. Change of Temporary Media
>
> After a temporary media stream has been established, its parameters
> can be changed by sending further provisional responses that also
> contain session descriptions. Upon receipt of such a response, the
> client MUST immediately cease transmission of media relating to the
> old temporary stream. As before, the new temporary media stream is
> established after acknowledgement of the provisional response.
>
> Provisional responses which contain no session description SHOULD NOT
> have an effect on any currently established temporary media stream.
>
>
> 5.11.7 Caller Receives 183 Response
>
> When the calling UA receives a 183 response that contains a session
> description and an indication that the session description is for
> early media, it SHALL setup the associated media session and present
> any media received from the called UA to the user.
>
>
> Again nothing is said about multiple 183 responses specifically, only
> about multiple provisional responses in general.
> So, is there anything that can be done to resolve this issue?
> Thanx,
> Irina
>
> --
> ================================================================
>
> Distinti saluti
> --
>
> Irina Ivanova
> Settore Sviluppo MasterVoice
>
> tel: +39 0522 1846007
> fax: +39 0522 331673
> mob: +39 334 6449290
> e-mail: i.ivanova at mastervoice.it
> web: www.mastertraining.it - www.registroelettronico.com
>
> Master Training S.r.l.
> Sede Legale: via Timolini, 18 - Correggio (RE) - Italy
> Sede Operativa: via Sani, 15 - Reggio Emilia - Italy
> Sede Commerciale: via Sani, 9 - Reggio Emilia - Italy
>
> ================================================================
> Le informazioni contenute in questa e-mail sono da considerarsi confidenziali e esclusivamente per uso personale dei destinatari sopra indicati. Questo messaggio può includere dati personali o sensibili. Qualora questo messaggio fosse da Voi ricevuto per errore vogliate cortesemente darcene notizia a mezzo e-mail e distruggere il messaggio ricevuto erroneamente. Quanto precede ai fini del rispetto del Decreto Legislativo 196/2003 sulla tutela dei dati personali e sensibili.
> This e-mail and any file transmitted with it is intended only for the person or entity to which is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure.Copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this e-mail by mistake, please notify us immediately by telephone or fax.
>
>
> _______________________________________________
> FreeSWITCH-dev mailing list
> FreeSWITCH-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20101027/19692417/attachment.html
More information about the FreeSWITCH-dev
mailing list