Subject: [SIP] Re: SIP digest, Vol 1 #639 - 10 msgs

From: rufin soh <[email-masked]>
Date: Wed, 27 Dec 2000 04:38:32 +0100 (CET)

Dearv All
My question today is, when a proxy forwards a 200
response and never receives a bye, nor a cancel after
he supposes that communication is already established,

how do you handle such a case?
It is said in the drafts that every SIP server must
support unknown messages, but in this case, I think we
can't rely on those messages in our implementation.
I have though that It could be possible for proxies
also to contact any UAS, as they do with UAC's
registered on their directory, do you think that issue
possible?(It could solve many message digest
problems).

Thanks

--- [email-masked] a écrit : > Send
SIP mailing list submissions to
> 	[email-masked]
> 
> To subscribe or unsubscribe via the World Wide Web,
> visit
> 	http://lists.bell-labs.com/mailman/listinfo/sip
> or, via email, send a message with subject or body
> 'help' to
> 	[email-masked]
> 
> You can reach the person managing the list at
> 	[email-masked]
> 
> When replying, please edit your Subject line so it
> is more specific
> than "Re: Contents of SIP digest..."
> 
> > Today's Topics:
> 
>    1. conflict in syntax (laks hmi)
>    2. Consultation (Ford Cheng (Leela))
>    3. Parser for Sip messages (Vijeth  D)
>    4. Re: Parser for Sip messages
> ([email-masked])
>    5. Re: Consultation ([email-masked])
>    6. e-mail [email-masked] (Divya  Nath)
>    7. CPL and new XML options. (Anuraj Ennai)
>    8. RE: CPL and new XML options. (Rosen, Brian)
>    9. Re: Parser for Sip messages (Henning
> Schulzrinne)
>   10. Encounter error in SDP during parsing (Deepak 
> Mohan)
> 

> ATTACHMENT part 3.1 message/rfc822 
> Date: Mon, 25 Dec 2000 20:28:07 -0800 (PST)
> De: laks hmi <[email-masked]>
> Objet:  [SIP] conflict in syntax
> À: Christian Jansson <[email-masked]>,
> [email-masked]
> 
>  >i have clearly mentioned in first mail where
> exactly
> the conflict is coming, once again i am explaining
> below.
> > Contact =  ( "Contact" | "m")":" ("*"
> > | (1# (( name-addr | addr-spec ) *( ";"
> > contact-params ))))
> 
> In the above syntax, (1# (( name-addr | addr-spec )
> is
> there in the beginning of the header after colon.
> SIP_URL | URI is coming in addr-spec is the first
> parameter can end with semicolon and token which
> is there in the generic-param of the other-params
> is conflicting with immediate *(";" contact-params )
> where again semicolon and token will come.
> 
> In this both other-param in URL and *( ";"
> contact-params ) can come zero or multiple times, so
> we 
> will not be knowing which parameter.
> 
> Regards
> lakshmi
> 
> 
> --- Christian Jansson <[email-masked]> wrote:
> > Just a few lines below the Contact syntax there is
> a
> > sentence that
> > I think will solve your problem:
> > 
> > "Even if the "display-name"is empty, the
> "name-addr"
> > form MUST be
> > used if the "addr-spec" contains a comma,
> semicolon
> > or question mark."
> > 
> > ---
> > Christian Jansson
> > 
> > >The syntax is as foloows
> > >Contact =  ( "Contact" | "m")":" ("*"
> > >| (1# (( name-addr | addr-spec ) *( ";"
> > >contact-params ))))
> > 
> > >i am telling abt (1# (( name-addr | addr-spec ),
> > where
> > >SIP-URL and URI is coming in address-spec and not
> > in
> > >the name-adress.
> > 
> > >Regards
> > >lakshmi
> > 
> > 
> > 
> > --- Hisham Khartabil <[email-masked]>
> > wrote:
> > > name-addr = [display-name] "<" addr-spec ">"
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: [email-masked]
> > > > [mailto:[email-masked]]On
> Behalf
> > Of
> > > laks hmi
> > > > Sent: Friday, 22 December 2000 11:50 AM
> > > > To: Hisham Khartabil
> > > > Cc: [email-masked]
> > > > Subject: RE: [SIP] conflict in syntax
> > > > 
> > > > 
> > > > what Mr.Hisham has told is correct but as i
> told
> > > only
> > > > in name-addr they have specified the "<" and
> > ">".
> > > > what abt the SIP-URL|URI in address-spec.
> > > > 
> > > > lakshmi
> > > > 
> > > >
> > __________________________________________________
> > > > Do You Yahoo!?
> > > > Yahoo! Shopping - Thousands of Stores.
> Millions
> > of
> > > Products.
> > > > http://shopping.yahoo.com/
> > > > 
> > > >
> _______________________________________________
> > > > SIP mailing list
> > > > [email-masked]
> > > >
> http://lists.bell-labs.com/mailman/listinfo/sip
> > > 
> > > _______________________________________________
> > > SIP mailing list
> > > [email-masked]
> > > http://lists.bell-labs.com/mailman/listinfo/sip
> > 
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! Shopping - Thousands of Stores. Millions of
> > Products.
> > http://shopping.yahoo.com/
> > 
> > _______________________________________________
> > SIP mailing list
> > [email-masked]
> > http://lists.bell-labs.com/mailman/listinfo/sip
> > 
> > 
> > _______________________________________________
> > SIP mailing list
> > [email-masked]
> > http://lists.bell-labs.com/mailman/listinfo/sip
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Shopping - Thousands of Stores. Millions of
> Products.
> http://shopping.yahoo.com/
> 
> 

> ATTACHMENT part 3.2 message/rfc822 
> De: "Ford Cheng (Leela)" <[email-masked]>
> À: [email-masked]
> Date: Tue, 26 Dec 2000 11:01:21 +0500
> Objet: [SIP] Consultation
> 
> Dear All:
>      I have one question to consult,
> on page 94-95 of  RFC2543 bis02, there is no
> detailed 
> algorithm on the generation of nonce, I read
> RFC2617,
> there is no algorithm on the generation of nonce.
> Could 
> anyone give me some suggestion on the generation of 
> nonce?
>     Thanks in advance!
>                                     
> 
> 
> 

> ATTACHMENT part 3.3 message/rfc822 
> Date: 26 Dec 2000 05:45:09 -0000
> À: [email-masked] <[email-masked]>
> De: "Vijeth  D" <[email-masked]>
> Objet: [SIP] Parser for Sip messages
> 
> Hi,
> A parser generating tool normally generates a very
> huge parser for even simple syntaxes. So is it
> better to write a hand decoder i.e., a manual
> decoder for the SIP messages? How safe is it to
> write a manual decoder say in C using the string
> library?
> 
> 
> 
> 
>
_____________________________________________________
> Chat with your friends as soon as they come online.
> Get Rediff Bol at
> http://bol.rediff.com
> 
> 
> 
> 
> 
> 

> ATTACHMENT part 3.4 message/rfc822 
> De: [email-masked]
> À: "Vijeth D" <[email-masked]>
> CC: "[email-masked]"
> <[email-masked]>
> Date: Tue, 26 Dec 2000 11:26:56 +0530
> Objet: Re: [SIP] Parser for Sip messages
> 
> 
> 
> 
> A parser generating tool normally generates a very
> huge parser for even
> simple syntaxes. So is it
> 
> arjun> Not always true. Such tools are especially
> effective when the
> grammar is large. If
> arjun> you want to design a parser that is really as
> flexible as the ABNF
> along with doing
> arjun> a complete parse, a tool may not be a bad
> idea. However, if your
> application requirements
> arjun> are less stringent, you can make a lower foot
> print hand made
> parser. What you select
> arjun> is really upto you. I dont want to open
> another inconclusive hand vs
> tool generated
> arjun> debate.
> arjun> Note however that *how* you use an automated
> tool is very important.
> Ive seen some false
> arjun> comments floating around about certain tools
> without the posters
> having studied them
> arjun> well. I would suggest that you first do a
> detailed study of
> available optimisations before
> arjun> you conclude. Flex and bison are two very
> flexible tools you can
> look at. I think someone
> arjun> else suggested Lemon, antlr etc - havent
> tried them.
> 
> 
> Regds
> Arjun
> --
> Arjun Roychowdhury @ Hughes Software Systems
> 
> 
> 
> 
> 
>
_____________________________________________________
> Chat with your friends as soon as they come online.
> Get Rediff Bol at
> http://bol.rediff.com
> 
> 
> 
> 
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip
> 
> 
> 
> 
> 
> 

> ATTACHMENT part 3.5 message/rfc822 
> De: [email-masked]
> À: "Ford Cheng (Leela)" <[email-masked]>
> CC: [email-masked]
> Date: Tue, 26 Dec 2000 11:53:18 +0530
> Objet: Re: [SIP] Consultation
> 
> 
> 
> One way is to form a nonce is to form a string using
> your timestamp and
> private key and calling
> encodeBase64(x,y) over it.  encodeBase64 source is
> available from a variety
>  of places, if you dont want to implement
> it yourself .
> 
> The algorithm you use really depends on how strong
> you want your nonce
> value to be. There is afaik, no
> one way to do it. The above is one algorithm - can
> use any other you deem
> fit.
> 
> Regds
> Arjun
> 
> 
> 
> 
> 
> 
> "Ford Cheng (Leela)" <[email-masked]> on
> 12/26/2000 11:31:21 AM
> 
> To:   [email-masked]
> cc:
> 
> Subject:  [SIP] Consultation
> 
> 
> 
> 
> Dear All:
>      I have one question to consult,
> on page 94-95 of  RFC2543 bis02, there is no
> detailed
> algorithm on the generation of nonce, I read
> RFC2617,
> there is no algorithm on the generation of nonce.
> Could
> anyone give me some suggestion on the generation of
> nonce?
>     Thanks in advance!
> 
> 
> 
> 
> 
<HR>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html;
charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server
version 5.5.2650.12">
<TITLE>Consultation</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2 FACE="Arial">Dear All:</FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp;&nbsp;&nbsp;
I have one question to consult,</FONT>
<BR><FONT SIZE=2 FACE="Arial">on page 94-95 of&nbsp;
RFC2543 bis02, there is no detailed </FONT>
<BR><FONT SIZE=2 FACE="Arial">algorithm on the
generation of nonce, I read RFC2617,</FONT>
<BR><FONT SIZE=2 FACE="Arial">there is no algorithm on
the generation of nonce. Could </FONT>
<BR><FONT SIZE=2 FACE="Arial">anyone give me some
suggestion on the generation of </FONT>
<BR><FONT SIZE=2 FACE="Arial">nonce?</FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp;&nbsp;
Thanks in advance!<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>

</P>
<BR>

</BODY>
</HTML>

> ATTACHMENT part 3.6 message/rfc822 
> Date: 26 Dec 2000 08:27:45 -0000
> À: [email-masked] <[email-masked]>
> De: "Divya  Nath" <[email-masked]>
> Objet: [SIP] e-mail [email-masked]
> 
> my email address is 
> 
> [email-masked]
> 
>
_____________________________________________________
> Chat with your friends as soon as they come online.
> Get Rediff Bol at
> http://bol.rediff.com
> 
> 
> 
> 
> 
> 

> ATTACHMENT part 3.7 message/rfc822 
> Date: Tue, 26 Dec 2000 15:14:40 +0530
> De: "Anuraj Ennai" <[email-masked]>
> Affiliation: Wipro
> À: sip <[email-masked]>
> Objet: [SIP] CPL and new XML options.
> 
> Hi all,
> I know this is not the place to raise issues about
> CPL.
> But still, it seems appropriate to discuss it with a
> wider audience.
> 
> It is evident that the intent of CPL is not just
> data
> representation (pure XML as portable data), but also
> processing of certain criteria. In the present CPL
> format,
> the processing instructions and data represenation
> are
> intertwined  together, limiting the application
> scope.
> (Eg. matching of strings, conditional branches etc
> provided
> in the XML doc itself.)
> 
> I believe it will be beneficial to separate both
> aspects.
> Use the XML format for data and XSL/XSLT with
> emerging XPATH/XPOINTER specs for filtering/
> processing. This will make the representation and
> processing independent providing more flexibility
> to applications using CPL.
> 
> Any way, CPL is still evolving and this might be the
> way
> to go. And in the end, am I making any sense?
> 
> Thanks & regards
> Anuraj Ennai
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 

> ATTACHMENT part 3.8 message/rfc822 
> De: "Rosen, Brian" <[email-masked]>
> À: "'Anuraj Ennai'" <[email-masked]>,
> 	sip <[email-masked]>
> Objet: RE: [SIP] CPL and new XML options.
> Date: Tue, 26 Dec 2000 09:54:07 -0500
> 
> You are correct, this is NOT the place to discuss
> CPL.
> 
> Please take this discussion to the iptel list.
> 
> Thanks
> 
> Brian
> 
> > -----Original Message-----
> > From: Anuraj Ennai [mailto:[email-masked]]
> > Sent: Tuesday, December 26, 2000 4:45 AM
> > To: sip
> > Subject: [SIP] CPL and new XML options.
> > 
> > 
> > Hi all,
> > I know this is not the place to raise issues about
> CPL.
> > But still, it seems appropriate to discuss it with
> a
> > wider audience.
> > 
> > It is evident that the intent of CPL is not just
> data
> > representation (pure XML as portable data), but
> also
> > processing of certain criteria. In the present CPL
> format,
> > the processing instructions and data represenation
> are
> > intertwined  together, limiting the application
> scope.
> > (Eg. matching of strings, conditional branches etc
> provided
> > in the XML doc itself.)
> > 
> > I believe it will be beneficial to separate both
> aspects.
> > Use the XML format for data and XSL/XSLT with
> > emerging XPATH/XPOINTER specs for filtering/
> > processing. This will make the representation and
> > processing independent providing more flexibility
> > to applications using CPL.
> > 
> > Any way, CPL is still evolving and this might be
> the way
> > to go. And in the end, am I making any sense?
> > 
> > Thanks & regards
> > Anuraj Ennai
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > SIP mailing list
> > [email-masked]
> > http://lists.bell-labs.com/mailman/listinfo/sip
> > 
> 
> 

> ATTACHMENT part 3.9 message/rfc822 
> Date: Tue, 26 Dec 2000 10:24:00 -0800
> De: Henning Schulzrinne <[email-masked]>
> Affiliation: Columbia University
> À: Vijeth D <[email-masked]>
> CC: "[email-masked]"
> <[email-masked]>
> Objet: Re: [SIP] Parser for Sip messages
> 
> A hand-crafted parser for the basic SIP (and RTSP
> and HTTP) structures
> takes a few hundred lines, with a few more for the
> specific fields,
> depending on needs. Not difficult, but does require
> extensive testing of
> the corner cases (spacing, line folding). The
> torture tests are helpful
> here.
> 
> Vijeth D wrote:
> > 
> > Hi,
> > A parser generating tool normally generates a very
> huge parser for even simple syntaxes. So is it
> better to write a hand decoder i.e., a manual
> decoder for the SIP messages? How safe is it to
> write a manual decoder say in C using the string
> library?
> > 
> >
>
_____________________________________________________
> > Chat with your friends as soon as they come
> online. Get Rediff Bol at
> > http://bol.rediff.com
> > 
> > _______________________________________________
> > SIP mailing list
> > [email-masked]
> > http://lists.bell-labs.com/mailman/listinfo/sip
> 
> 

> ATTACHMENT part 3.10 message/rfc822 
> Date: 26 Dec 2000 15:26:22 -0000
> À: [email-masked] <[email-masked]>
> De: "Deepak  Mohan" <[email-masked]>
> Objet: [SIP] Encounter error in SDP during parsing
> 
> If a UAS comes across a protocol error in the SDP
> while parsing the INVITE/ACK, what is the usual
> response?
> 
> -Deepak
> 
>
_____________________________________________________
> Chat with your friends as soon as they come online.
> Get Rediff Bol at
> http://bol.rediff.com
> 
> 
> 
> 
> 
> 
> 
> > _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip
> 
> 

___________________________________________________________
Do You Yahoo!? -- Pour dialoguer en direct avec vos amis, 
Yahoo! Messenger : http://fr.messenger.yahoo.com

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Vijay Gurbani <[email-masked]>
Date: Wed, 27 Dec 2000 09:39:43 -0600

> how do you handle such a case?

The answer to your question depends on the statefulness of the proxy.  If
the proxy is stateless, it will not care after proxying the 200 OK (INVITE)
upstream, and furthermore, the ACK to the INVITE will go directly to the 
UAS, as will the ensuing BYE.  

If the proxy is call-stateful (and thus included a Record-Route), then it 
MUST see an ACK.  Now, assume that the UAC crashes after receiving the 200 
OK but before sending the ACK.  The call-stateful proxy is waiting for the 
ACK, as is the downstream UAS.  Since the downstream UAS does not get an 
ACK, it will retransmit the 200 OK upto to a maximum of 7 times and then 
give up.  Presumably, the proxy can count the number of 200 OKs send 
upstream and clean state after the 7th retransmission.

Note that if a call-stateful proxy forwarded a 200 OK (INVITE) upstream, it 
WILL expect an ACK for its state machinery.  Even if the upstream UAC 
rejected the call by sending a BYE, it has to send an ACK to complete the 
INVITE transaction.

> can't rely on those messages in our implementation.

Ummm, which unknown message are you referring to?

> possible?(It could solve many message digest

Proxies do not, on their own, contact UASes.  They only contact the UAS on
behalf of a request initiated by the UAC.

Regards,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Internet Software and eServices Group 
Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., Rm 1A-413
Naperville, Illinois 60566     Voice: +1 630 224 0216   Fax: +1 630 713 0184