Dear friends,
Is there any RFC for SIP-ALG ?
Thanks
Tapan
On Wed, Mar 4, 2009 at 8:28 PM, <
[email protected]> wrote:
> 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. Registration for SIPit 24 is open (Robert Sparks)
> 2. Re: Regarding RFC 3263 (Dale Worley)
> 3. Privacy values (I?aki Baz Castillo)
> 4. Re: Privacy values (I?aki Baz Castillo)
> 5. Re: Privacy values (Neelakantan Balasubramanian)
> 6. Re: Privacy values (I?aki Baz Castillo)
> 7. Re: Privacy values (Pandurangan R S)
> 8. When 408 for reINVITE, should UAC try to send BYE out or
> simply clean up the local resources? (hanifa.mohammed)
> 9. When register refresh receives 408, should UAC terminate all
> active calls? (hanifa.mohammed)
> 10. Re: When 408 for reINVITE, should UAC try to send BYE out or
> simply clean up the local resources? (I?aki Baz Castillo)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 3 Mar 2009 10:51:29 -0600
> From: Robert Sparks <[email protected]>
> Subject: [Sip-implementors] Registration for SIPit 24 is open
> To: "[email protected] Implementors"
> <[email protected]>
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>
> Registration for SIPit 24 is open!
> SIPit 24 will be held May 18-22, 2009 in Akihabara, Tokyo, Japan
> hosted by JPNIC and NICT.
> Additional information is available at http://www.sipit.net and
> http://www.nic.ad.jp/en/sipit24/
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 03 Mar 2009 12:00:45 -0500
> From: "Dale Worley" <[email protected]>
> Subject: Re: [Sip-implementors] Regarding RFC 3263
> To: I?aki Baz Castillo <[email protected]>
> Cc: [email protected]
> Message-ID:
> <[email protected]>
> Content-Type: text/plain; charset=utf-8
>
>
> On Tue, 2009-03-03 at 11:34 +0100, I?aki Baz Castillo wrote:
> > 2009/3/3 sarvpriya <[email protected]>:
> > > hello,
> > > I am currently implementing RFC 3263. My SIP application only supports
> UDP.
> > > I want to know that while sending outgoing requests or responses, if it
> > > fails then alternate address needs to be tried. Can you please give
> > > definition of this "fails"
> >
> > > 1) it could be transport error ( vat kind of transport error for UDP)
> >
> > Yes.
>
> In particular, you could receive an ICMP Port Unreachable message.
>
> > > 3) similarly while sending in dialog request say info, if I dnt get
> reply to
> > > info, then shud i contact alternate ip addresses?
> >
> > No, when you send an in-dialog request the destination is the
> > remote-target (the other endpoint "Contact" header URI). That URI
> > contains a definitive location, i.e:
> > - sip:[email protected] <sip%[email protected]> -> UDP 1.2.3.4:5060
> > - sip:[email protected]:6666;transport=TCP -> TCP 1.2.3.4:6666
> > - sip:[email protected]:5082;transport=UDP -> UDP 1.2.3.4:5082
> >
> > In all these cases there is not (and there cannot be) an alternative
> > address, since the peer you are speaking with has, usually, just one
> > contact address.
>
> However, Contact and Route URIs can contain host names rather than IP
> addresses, and a SIP element is required to handle these correctly. (In
> particular, GRUUs will *always* contain host names.) Many phones handle
> this situation correctly; ones that do not should be avoided.
>
> The addresses in Via headers can also contain host names, although very
> few phones handle them correctly. This is quite a problem, as it makes
> it difficult for one SIP proxy to take over for another during a dialog.
>
> Dale
>
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 3 Mar 2009 23:51:10 +0100
> From: I?aki Baz Castillo <[email protected]>
> Subject: [Sip-implementors] Privacy values
> To: [email protected]
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset="utf-8"
>
> Hi, RFC 3325 just mentions the "id" [1] value for Privacy header, but
> according to RFC 3323 there are various types of privacy an user can
> request
>
> Where could i read more about them? Are they really useful? Are they really
> implemented?
>
> Thanks.
>
> [1] http://tools.ietf.org/html/rfc3325#section-9.3
>
> --
> I?aki Baz Castillo
>
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 3 Mar 2009 23:58:02 +0100
> From: I?aki Baz Castillo <[email protected]>
> Subject: Re: [Sip-implementors] Privacy values
> To: [email protected]
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset="utf-8"
>
> El Martes, 3 de Marzo de 2009, I?aki Baz Castillo escribi?:
> > Hi, RFC 3325 just mentions the "id" [1] value for Privacy header, but
> > according to RFC 3323 there are various types of privacy an user can
> > request
>
> Update: RFC 3325 also mentions "Privacy: none" (the same as the no
> existance
> of Privacy header).
>
>
> --
> I?aki Baz Castillo
>
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 3 Mar 2009 14:58:48 -0800
> From: Neelakantan Balasubramanian <[email protected]>
> Subject: Re: [Sip-implementors] Privacy values
> To: I?aki Baz Castillo <[email protected]>,
> "[email protected]"
> <[email protected]>
> Message-ID:
> <[email protected]>
> Content-Type: text/plain; charset="utf-8"
>
> See below.
>
>
> > -----Original Message-----
> > From: [email protected] [mailto:sip-
> > [email protected]] On Behalf Of I?aki Baz
> > Castillo
> > Sent: Tuesday, March 03, 2009 4:51 PM
> > To: [email protected]
> > Subject: [Sip-implementors] Privacy values
> >
> > Hi, RFC 3325 just mentions the "id" [1] value for Privacy header, but
> > according to RFC 3323 there are various types of privacy an user can
> > request
> >
> [Neel]
> I noticed "user" in RFC 5079. RFC 4244 provides "history".
>
> > Where could i read more about them? Are they really useful? Are they
> > really
> > implemented?
> >
> > Thanks.
> >
> > [1] http://tools.ietf.org/html/rfc3325#section-9.3
> >
> > --
> > I?aki Baz Castillo
> >
> > _______________________________________________
> > Sip-implementors mailing list
> > [email protected]
> > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
>
>
> ------------------------------
>
> Message: 6
> Date: Wed, 4 Mar 2009 00:01:25 +0100
> From: I?aki Baz Castillo <[email protected]>
> Subject: Re: [Sip-implementors] Privacy values
> To: [email protected]
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset="utf-8"
>
> El Martes, 3 de Marzo de 2009, Neelakantan Balasubramanian escribi?:
> > See below.
> >
> > > -----Original Message-----
> > > From: [email protected] [mailto:sip-
> > > [email protected]] On Behalf Of I?aki Baz
> > > Castillo
> > > Sent: Tuesday, March 03, 2009 4:51 PM
> > > To: [email protected]
> > > Subject: [Sip-implementors] Privacy values
> > >
> > > Hi, RFC 3325 just mentions the "id" [1] value for Privacy header, but
> > > according to RFC 3323 there are various types of privacy an user can
> > > request
> >
> > [Neel]
> > I noticed "user" in RFC 5079. RFC 4244 provides "history".
>
> Thanks.
>
> --
> I?aki Baz Castillo
>
>
>
> ------------------------------
>
> Message: 7
> Date: Wed, 4 Mar 2009 09:13:47 +0530
> From: Pandurangan R S <[email protected]>
> Subject: Re: [Sip-implementors] Privacy values
> To: I?aki Baz Castillo <[email protected]>
> Cc: [email protected]
> Message-ID:
> <[email protected]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> http://www.iana.org/assignments/sip-priv-values
>
> On Wed, Mar 4, 2009 at 4:21 AM, I?aki Baz Castillo <[email protected]> wrote:
> > Hi, RFC ?3325 just mentions the "id" [1] value for Privacy header, but
> > according to RFC 3323 there are various types of privacy an user can
> request
> >
> > Where could i read more about them? Are they really useful? Are they
> really
> > implemented?
> >
> > Thanks.
> >
> > [1] http://tools.ietf.org/html/rfc3325#section-9.3
> >
> > --
> > I?aki Baz Castillo
> >
> > _______________________________________________
> > Sip-implementors mailing list
> > [email protected]
> > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
>
>
> ------------------------------
>
> Message: 8
> Date: Wed, 4 Mar 2009 20:01:09 +0530
> From: "hanifa.mohammed" <[email protected]>
> Subject: [Sip-implementors] When 408 for reINVITE, should UAC try to
> send BYE out or simply clean up the local resources?
> To: <[email protected]>
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi all,
>
> an excerpt from rfc 3261:
> if the response for a request within a dialog is a 481 (Call/Transaction
> Does Not Exist) or a 408 (Request Timeout), the UAC SHOULD terminate the
> dialog. A UAC SHOULD also terminate a dialog if no response at all is
> received for the request (the client transaction would inform the TU about
> the timeout.) For INVITE initiated dialogs, terminating the dialog consists
> of sending a BYE.
>
> Is it necessary to send a BYE request out to the network? Bcoz, it is
> obvious that it will also get the same resp. cant UAC simply
>
> clean the local resource and inform the user that the dialog is closed.
>
> Or BYE is needed for the intermediate stateful proxies to clear the call
> context? If s, cant the proxies clear their context on
>
> receiving 481 or 408 for the in-dialog request?
>
>
> Best Regards,
> Mohammed Hanifa
>
> ----- Original Message -----
> From: Pandurangan R S
> To: I?aki Baz Castillo
> Cc: [email protected]
> Sent: Wednesday, March 04, 2009 9:13 AM
> Subject: Re: [Sip-implementors] Privacy values
>
>
> http://www.iana.org/assignments/sip-priv-values
>
> On Wed, Mar 4, 2009 at 4:21 AM, I?aki Baz Castillo <[email protected]> wrote:
> > Hi, RFC 3325 just mentions the "id" [1] value for Privacy header, but
> > according to RFC 3323 there are various types of privacy an user can
> request
> >
> > Where could i read more about them? Are they really useful? Are they
> really
> > implemented?
> >
> > Thanks.
> >
> > [1] http://tools.ietf.org/html/rfc3325#section-9.3
> >
> > --
> > I?aki Baz Castillo
> >
> > _______________________________________________
> > 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
>
> ------------------------------
>
> Message: 9
> Date: Wed, 4 Mar 2009 20:10:19 +0530
> From: "hanifa.mohammed" <[email protected]>
> Subject: [Sip-implementors] When register refresh receives 408,
> should UAC terminate all active calls?
> To: <[email protected]>
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi all,
>
> Normally, UAC refreshes at half interval of the expires value. i.e. for
> every half an hr if
> the expires value in 200 is 1 hr/
>
> When register refresh receives 408,
> - should UAC immed terminate all active session such as call,
> subscription, ...?
> - should retry periodically till 1hr expires? Even after 1 hr, if
> there is no resp, then clean up all sessions.=20
>
> Pl clarify.
> Thanks in advance.
>
> Best Regards,
> Mohammed Hanifa
>
>
> ------------------------------
>
> Message: 10
> Date: Wed, 4 Mar 2009 15:58:23 +0100
> From: I?aki Baz Castillo <[email protected]>
> Subject: Re: [Sip-implementors] When 408 for reINVITE, should UAC try
> to send BYE out or simply clean up the local resources?
> Cc: [email protected]
> Message-ID:
> <[email protected]>
> Content-Type: text/plain; charset=UTF-8
>
> 2009/3/4 hanifa.mohammed <[email protected]>:
> > Hi all,
> >
> > an excerpt from rfc 3261:
> > ?if the response for a request within a dialog is a 481 (Call/Transaction
> Does Not Exist) or a 408 (Request Timeout), the UAC SHOULD terminate the
> dialog. A UAC SHOULD also terminate a dialog if no response at all is
> received for the request (the client transaction would inform the TU about
> the timeout.) For INVITE initiated dialogs, terminating the dialog consists
> of sending a BYE.
> >
> > Is it necessary to send a BYE request out to the network? Bcoz, it is
> obvious that it will also get the same resp. cant UAC simply clean the local
> resource and inform the user that the dialog is closed.
>
> There is nothing wrong in sending the BYE even if most probably it
> won't arrive to the UAS.
>
>
> > Or BYE is needed for the intermediate stateful proxies to clear the call
> context?
>
> A stateful proxy is not call stateful proxy, so it's not dialog aware.
> There are stateful proxies with some limited dialog support. In these
> cases, I think they shouldn't react on receiving 481 or 408 for an
> in-dialog request. They must remain being *proxies*.
> Also, if the UAC sends a BYE after the 408/481, these proxies will be
> happy and can clean the dialog context.
>
>
> > If so, cant the proxies clear their context on receiving 481 or 408 for
> the in-dialog request?
>
> They shouldn't, it's not a proxy task. Leave the proxies acting as proxies
> :)
>
>
> --
> I?aki Baz Castillo
> <[email protected]>
>
>
>
> ------------------------------
>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
> End of Sip-implementors Digest, Vol 72, Issue 8
> ***********************************************
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
