Hi Dushyant, This is not a bug or understanding problem, we also thought the same way, but this is specified only for the proxies which explicitly needs this feature, In such a case they can establish it, Also this will be very specific to the few scenarios where the traffic is too high so that the proxies need this feature irrespective of UAC or UAS, so that they can maintain there resources, also as per rfc 1800 seconds is anyways a long time for a call, so ideally there shouldn't be any problem.
Also even if Proxy wants to use this feature, they should always become refresher as both UAS/UAC will always respond to ReInvite( as refresher reInvite) and they will just renegotiate the old SDP/new SDP depending on the scenario. But still we haven't anywhere, where such proxy usage is present. Thankz and regards Girish T HUAWEI TECHNOLOGIES CO.,LTD. huawei_logo ---------------------------------------------------------------------------- --------------------------------------------------------- This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Wednesday, November 25, 2009 3:04 AM To: [email protected] Subject: Sip-implementors Digest, Vol 80, Issue 17 Send Sip-implementors mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of Sip-implementors digest..." Today's Topics: 1. Clarification regarding RFC 4028 Session Expiration (Dushyant Dhalia) 2. Re: [RPort] Request to know unique use case ofrport (Attila Sipos) 3. Re: Clarification regarding RFC 4028 Session Expiration (Pandurangan R S) 4. Re: [RPort] Request to know unique use case ofrport (I?aki Baz Castillo) 5. Re: [RPort] Request to know unique use caseofrport (Attila Sipos) 6. Clarification of Redirect originator (Brez Borland) 7. Re: [RPort] Request to know unique use caseofrport (Alex Balashov) ---------------------------------------------------------------------- Message: 1 Date: Tue, 24 Nov 2009 17:24:44 +0530 From: Dushyant Dhalia <[email protected]> Subject: [Sip-implementors] Clarification regarding RFC 4028 Session Expiration To: [email protected] Message-ID: <[email protected]> Content-Type: text/plain; charset="us-ascii" An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/sip-implementors/attachments/2009112 4/6924522f/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: dushyant_dhalia.vcf Type: text/x-vcard Size: 213 bytes Desc: not available Url : https://lists.cs.columbia.edu/pipermail/sip-implementors/attachments/2009112 4/6924522f/dushyant_dhalia-0001.vcf ------------------------------ Message: 2 Date: Tue, 24 Nov 2009 12:12:34 -0000 From: "Attila Sipos" <[email protected]> Subject: Re: [Sip-implementors] [RPort] Request to know unique use case ofrport To: "Vivek Batra" <[email protected]> Cc: [email protected], [email protected] Message-ID: <[email protected]> Content-Type: text/plain; charset="us-ascii" >>UA needs to know and publish its public IP address/port. this is true in some cases. If you are a standalone UA (not using a SIP server) and want to receive requests, then rport is not good enough. (but of course, you still need an external STUN server) In other cases, a SIP server (with which the SIP UA is registered) will be on the "outside". In this case I believe the SIP server (which accepts the registrations) will remember which port was used for responses and will direct future requests there. This is how it works in rfc 5626 (Managing Client-Initiated Connections in SIP) for UDP SIP signalling. Regards Attila -----Original Message----- From: Vivek Batra [mailto:[email protected]] Sent: 24 November 2009 11:49 To: Attila Sipos Cc: [email protected]; [email protected] Subject: RE: [Sip-implementors] [RPort] Request to know unique use case ofrport Attila, [Attila] - "rport is a very simple mechanism without very low overhead for achieving simple NAT traversal without requiring a separate protocol such as STUN which requires a STUN client and STUN server" [Vivek] - Even rport is used, I think STUN mechanism will still be required since rport will help only in getting responses across NAT, whereas to receive further transaction request, UA needs to know and publish its public IP address/port. Best Regards, Vivek Batra ------------------------------ Message: 3 Date: Tue, 24 Nov 2009 17:49:20 +0530 From: Pandurangan R S <[email protected]> Subject: Re: [Sip-implementors] Clarification regarding RFC 4028 Session Expiration To: Dushyant Dhalia <[email protected]> Cc: [email protected] Message-ID: <[email protected]> Content-Type: text/plain; charset=ISO-8859-1 > That essentially means neither UAC nor UAS supports RFC 4028 but P1 > and P2 run the session expiration timers as a result when the timer > times out both > P1 and P2 release their calls/ resources. This is not expected to occur as per RFC 4028. May be you should just elaborate how you think situation occurs if RFC's guidelines are followed. Regards Pandu On Tue, Nov 24, 2009 at 5:24 PM, Dushyant Dhalia <[email protected]> wrote: > ____ _ ??????????? ______?????????? ?? ? _____?????????????? _____ > | UAC | ______ | P1? ?? | _______ | P2?? | _______ | UAS | _____| > |?????????? |______|????????????? |_____|????????????? |_____| > > Consider the above configuration - > > UAC doesn't insert Session-Expires header in Initial INVITE. > RFC 4028 section 8.1 says that "A proxy MAY insert a Session-Expires > header field in the request before forwarding it if none was present > in the request." > P1 inserts Session-Expires header. > P2 receives INVITE with Session-Expires header and forwards it to UAS. > UAS doesn't support Session-Expires so it doen't insert this header in > the response. > The response arrives at P2. Now RFC 4028 section 8.2 says " > > When the final response to the request arrives, it is examined by the > proxy. > > If the response does not contain a Session-Expires header field but > the proxy remembers that it requested a session timer in the request > (by inserting, modifying, or examining and accepting the > Session-Expires header field in the proxied request), this means that > the UAS did not support the session timer. If the proxy remembers > that the UAC did not support the session timer either, the proxy > forwards the response upstream normally. There is no session > expiration for this session. If, however, the proxy remembers that > the UAC did support the session timer, additional processing is > needed. > > Because there is no Session-Expires or Require header field in the > response, the proxy knows that it is the first session-timer-aware > proxy to receive the response. This proxy MUST insert a > Session-Expires header field into the response with the value it > remembered from the forwarded request. It MUST set the value of the > 'refresher' parameter to 'uac'. > > ". > That essentially means neither UAC nor UAS supports RFC 4028 but P1 > and P2 run the session expiration timers as a result when the timer > times out both > P1 and P2 release their calls/ resources. In certain cases this could > be potential revenue loss scenario. > > Is it a bug or some gap in understanding? > > Dushyant P S Dhalia > Rancore Technologies, > Gurgaon, INDIA > > -- > "When work is a pleasure, life is a joy! When work is duty, life is > slavery." > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > ------------------------------ Message: 4 Date: Tue, 24 Nov 2009 13:26:24 +0100 From: I?aki Baz Castillo <[email protected]> Subject: Re: [Sip-implementors] [RPort] Request to know unique use case ofrport To: [email protected] Message-ID: <[email protected]> Content-Type: Text/Plain; charset="iso-8859-1" Hi Attila, could I suggest you to use a mail client which respects and implements the "In-Reply-To" header? Then when you reply in a thread your mail would include such header and would appear in the corresponding thread in any other RFC complian mail client. For now, every mail from you is a new "thread" in my mail client since it doesn't include the "In-Reply-To" header (the header a client should inspect to order the mails by threads). Regards. El Martes, 24 de Noviembre de 2009, Attila Sipos escribi?: > >>UA needs to know and publish its public IP address/port. > > this is true in some cases. If you are a standalone UA (not using a > SIP server) and want to receive requests, then rport is not good > enough. (but of course, you still need an external STUN server) -- I?aki Baz Castillo <[email protected]> ------------------------------ Message: 5 Date: Tue, 24 Nov 2009 13:06:13 -0000 From: "Attila Sipos" <[email protected]> Subject: Re: [Sip-implementors] [RPort] Request to know unique use caseofrport To: I?aki Baz Castillo <[email protected]>, <[email protected]> Message-ID: <[email protected]> Content-Type: text/plain; charset="iso-8859-1" At risk of getting a FAIL from Mr.Balashov, does anyone know anything about MS Outlook 2003 support for In-Reply-To? how to enable it? -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of I?aki Baz Castillo Sent: 24 November 2009 12:26 To: [email protected] Subject: Re: [Sip-implementors] [RPort] Request to know unique use caseofrport Hi Attila, could I suggest you to use a mail client which respects and implements the "In-Reply-To" header? Then when you reply in a thread your mail would include such header and would appear in the corresponding thread in any other RFC complian mail client. For now, every mail from you is a new "thread" in my mail client since it doesn't include the "In-Reply-To" header (the header a client should inspect to order the mails by threads). Regards. El Martes, 24 de Noviembre de 2009, Attila Sipos escribi?: > >>UA needs to know and publish its public IP address/port. > > this is true in some cases. If you are a standalone UA (not using a > SIP server) and want to receive requests, then rport is not good > enough. (but of course, you still need an external STUN server) -- I?aki Baz Castillo <[email protected]> _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ------------------------------ Message: 6 Date: Tue, 24 Nov 2009 21:32:39 +0000 From: Brez Borland <[email protected]> Subject: [Sip-implementors] Clarification of Redirect originator To: [email protected] Message-ID: <[email protected]> Content-Type: text/plain; charset=ISO-8859-1 Hi all, If I have UAC who is sending a REGISTER request trough proxy server. Proxy server sends this request further on to REGISTER server. REGISTER server sends a Redirect response to the proxy server. Now, should proxy server send this Redirect response to UAC, or should it try to send the REGISTER request to the address specified in Redirect? The RFC3261, 8.3 Redirect servers, say: When the originator of the request receives the redirection, it will send a new request based on the URI(s) it has received. By propagating URIs from the core of the network to its edges, redirection allows for considerable network scalability. My question is, can the proxy be considered as a request originator? Or is it strictly UAC. I am trying to solve this puzzle and fail to do it myself, please gurus of sip, I will greatly appreciate your help, Thank you, Regards, Brez ------------------------------ Message: 7 Date: Tue, 24 Nov 2009 16:33:50 -0500 From: Alex Balashov <[email protected]> Subject: Re: [Sip-implementors] [RPort] Request to know unique use caseofrport To: Attila Sipos <[email protected]> Cc: [email protected] Message-ID: <[email protected]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Why would that merit the response "FAIL?" Attila Sipos wrote: > At risk of getting a FAIL from Mr.Balashov, does > anyone know anything about MS Outlook 2003 support for In-Reply-To? > > how to enable it? > > > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of I?aki Baz Castillo > Sent: 24 November 2009 12:26 > To: [email protected] > Subject: Re: [Sip-implementors] [RPort] Request to know unique use caseofrport > > Hi Attila, could I suggest you to use a mail client which respects and implements the "In-Reply-To" header? Then when you reply in a thread your mail would include such header and would appear in the corresponding thread in any other RFC complian mail client. > > For now, every mail from you is a new "thread" in my mail client since it doesn't include the "In-Reply-To" header (the header a client should inspect to order the mails by threads). > > Regards. > > > El Martes, 24 de Noviembre de 2009, Attila Sipos escribi?: >>>> UA needs to know and publish its public IP address/port. >> this is true in some cases. If you are a standalone UA (not using a >> SIP server) and want to receive requests, then rport is not good >> enough. (but of course, you still need an external STUN server) > > > -- > I?aki Baz Castillo <[email protected]> > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 ------------------------------ _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors End of Sip-implementors Digest, Vol 80, Issue 17 ************************************************ _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
