hi, the attribute a=sendrecv is the one i used... is it possible i need to keep the CSeq from the first invite i sent (from the previous ip) ?
waiting call means that another call is sent to the receiver (same number TO and different ip) still help! On Tue, 2007-05-08 at 06:14 -0400, [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. Multiple 'm' lines in SDP and the reinvite behaviour (Kannaiyan) > 2. Re: A query regarding sip uri parsing (Vikram Chhibber) > 3. Re: Multiple 'm' lines in SDP and the reinvitebehaviour > (Rayees Khan) > 4. Re: Via Header size (Attila Sipos) > 5. Re: Multiple 'm' lines in SDP and the reinvitebehaviour > (Attila Sipos) > 6. Re: Multiple 'm' lines in SDP and thereinvitebehaviour > (Gaurav Kheterpal) > 7. Re: changing ip during call (Gaurav Kheterpal) > 8. Re: Multiple 'm' lines in SDP and the reinvitebehaviour > (Christer Holmberg (JO/LMF)) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 8 May 2007 16:33:29 +0800 > From: "Kannaiyan" <[EMAIL PROTECTED]> > Subject: [Sip-implementors] Multiple 'm' lines in SDP and the reinvite > behaviour > To: <[email protected]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; format=flowed; charset="iso-8859-1"; > reply-type=original > > Hi, > > When I offer in the initial invite, > > m=audio 3456 RTP/AVP 0 3 4 5 > m= video 4578 RTP/AVP 98 97 > m= audio 3487 RTP/AVP 0 3 4 5 > > later if I want to reinvite, is it possible to change it to, > > m=audio 3456 RTP/AVP 0 3 4 5 > m= video 4578 RTP/AVP 98 97 > > skipping the third line. > > 1. Is the reinvite of the missing third line is a Violation? > 2. What response should I send for this? > > Regards, > Kannaiyan > > > > > ------------------------------ > > Message: 2 > Date: Tue, 8 May 2007 14:31:12 +0530 > From: "Vikram Chhibber" <[EMAIL PROTECTED]> > Subject: Re: [Sip-implementors] A query regarding sip uri parsing > To: "Gayathri Madda" <[EMAIL PROTECTED]> > Cc: [email protected] > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > the url format that you have provided is not a sip therefore there is > no user and host part. The url format is tel therefore you need to > discard the host portion of that url. The user portion you need to > treat it as local tel number with phone-context, tgrp and > trunk-context as parameters. > > ~Vikram > On 5/4/07, Gayathri Madda <[EMAIL PROTECTED]> wrote: > > Hi all > > > > can u please suggest how to parse this as per ABNF Rule > > sip:5550100;phone-context=+1-630;tgrp=TG-1;trunk-context= > > [EMAIL PROTECTED];user=phone > > > > As per RFC we use "@" for parsing host and user part > > Here in this case : > > "5550100;phone-context=+1-630;tgrp=TG-1;trunk-context=example.com" is > > consider as user part and called party number is corrupted while mapping to > > H323 set up message. > > > > Thanks in Advance > > > > Regards > > Gayathri > > _______________________________________________ > > Sip-implementors mailing list > > [email protected] > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > > ------------------------------ > > Message: 3 > Date: Tue, 8 May 2007 10:01:31 +0100 > From: "Rayees Khan" <[EMAIL PROTECTED]> > Subject: Re: [Sip-implementors] Multiple 'm' lines in SDP and the > reinvitebehaviour > To: "Kannaiyan" <[EMAIL PROTECTED]>, > <[email protected]> > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="us-ascii" > > > The re-INVITE is invalid as far as OFFER-ANSWER id concerned. A new > OFFER should have all the media description of previous OFFER and can > add new ones. Though by changing port to '0', the stream can be set to > inactive. > A server would normally send a 400 response for such request, though I > am not sure of what warning header it would correspond to. > > regards > Rayees > > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Kannaiyan > Sent: Tuesday, May 08, 2007 9:33 AM > To: [email protected] > Subject: [Sip-implementors] Multiple 'm' lines in SDP and the > reinvitebehaviour > > Hi, > > When I offer in the initial invite, > > m=audio 3456 RTP/AVP 0 3 4 5 > m= video 4578 RTP/AVP 98 97 > m= audio 3487 RTP/AVP 0 3 4 5 > > later if I want to reinvite, is it possible to change it to, > > m=audio 3456 RTP/AVP 0 3 4 5 > m= video 4578 RTP/AVP 98 97 > > skipping the third line. > > 1. Is the reinvite of the missing third line is a Violation? > 2. What response should I send for this? > > Regards, > Kannaiyan > > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > > > > > ---------------------------------------------------------------------------------- > IMPORTANT The information contained in this e-mail any > attachments is intended only for the named recipient and may be > privileged or confidential. > > If you are not the intended recipient, please notify us immediately > on +44 (0)1908 425000 and do not disclose, copy, distribute > or take any action based on the contents of this e-mail. > > You should understand and accept that, when communicating with us > by e-mail, it is not a totally secure communication medium. > > We accept no liability for any direct, indirect or consequential loss > arising from any action taken in reliance on the information contained > in this e-mail and give no warranty or representation as to its accuracy > or reliability. > > DIGITALK has the facility to monitor and read both incoming > and outgoing communications by e-mail. In line with industry efforts > to reduce the proliferation of Un-Solicited SPAM messages, > DIGITALK uses various methods including Reverse-DNS > lookups and ban-lists to prevent malicious content reaching our users. > > This message and any attachments has been scanned for known > viruses. However, we would advise you to ensure the content is > indeed virus free. We do not, to the extent permitted by law, accept > any liability (whether in contract, negligence or otherwise) for any virus > infection and/or external compromise of security and/or breach of > confidentiality in relation to transmissions sent by e-mail. > > VAT No: GB 876 3287 81. Reg No: 3080801 > Place of Registration: England > Registered Office Address: 2 Radian Court, Knowlhill, Milton Keynes > ----------------------------------------------------------------------------------" > > > > > ------------------------------ > > Message: 4 > Date: Tue, 8 May 2007 10:11:03 +0100 > From: "Attila Sipos" <[EMAIL PROTECTED]> > Subject: Re: [Sip-implementors] Via Header size > To: "venkatesh chandran" <[EMAIL PROTECTED]>, > <[EMAIL PROTECTED]> > Cc: [email protected] > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="iso-8859-1" > > Hi Venkatesh, > > where can one find Table 5.1-1 that you refer to? > > Regards, > > Attila > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of venkatesh > chandran > Sent: 08 May 2007 05:41 > To: [EMAIL PROTECTED] > Cc: [email protected] > Subject: Re: [Sip-implementors] Via Header size > > > Hello *, > I have got the following information regarding message size details while > googling... > > The maximum length of each part of a message is shown in Table 5.1-1. The > length of the whole request/response messages > > exceed the path MTU. A SIP response message becomes longer than a SIP > request message, because the response message > > some headers such as Via and Record-Route that several SIP proxies added. > > Table 5.1-1 Maximum length > > URI 128 bytes > > Request line and status line 256 bytes > > 1 message header line 256 bytes > > The whole message header No limit (However, the whole message must not > exceed the maximum length.) > > 1 message body line in SDP No limit (However, SDP message body must not > exceed the maximum length below) > > SDP message body 1000 bytes > > The whole message body No limit (However, the whole message must not exceed > the maximum length.) > The whole request message [UDP] 1300 bytes, [TLS/TCP, TCP] 2700 bytes > > Best Regards, > Venkatesh > > > On 5/7/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > From: Jagan Mohan Reddy S <[EMAIL PROTECTED]> > > > > Is there any limit for the size of SIP header? > > > > No. > > > > PROTOS is sending an INVITE with too many (>200 bytes) of junk > > characters in VIA header. Can we treat this message as malformed > > message and drop the packet without doing further processing? > > > > Only if you want your product to not work with Protos, and all your > > competitors to ridicule your product for its lack of conformance to > > the standard. > > > > Dale > > _______________________________________________ > > 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: 5 > Date: Tue, 8 May 2007 10:21:14 +0100 > From: "Attila Sipos" <[EMAIL PROTECTED]> > Subject: Re: [Sip-implementors] Multiple 'm' lines in SDP and the > reinvitebehaviour > To: "Kannaiyan" <[EMAIL PROTECTED]>, > <[email protected]> > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="iso-8859-1" > > > > >>1. Is the reinvite of the missing third line is a Violation? > > No. > You can specify whatever you like. You can have different > codecs, ports or even media IP addresses. > > >>2. What response should I send for this? > > I'm not sure what to say except that it's all in RFC3264. > I think the most important point is that for all m= lines > in the offer, there must be a corresponding m= line in > the answer. > > Regards, > > Attila > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Kannaiyan > Sent: 08 May 2007 09:33 > To: [email protected] > Subject: [Sip-implementors] Multiple 'm' lines in SDP and the > reinvitebehaviour > > > Hi, > > When I offer in the initial invite, > > m=audio 3456 RTP/AVP 0 3 4 5 > m= video 4578 RTP/AVP 98 97 > m= audio 3487 RTP/AVP 0 3 4 5 > > later if I want to reinvite, is it possible to change it to, > > m=audio 3456 RTP/AVP 0 3 4 5 > m= video 4578 RTP/AVP 98 97 > > skipping the third line. > > 1. Is the reinvite of the missing third line is a Violation? > 2. What response should I send for this? > > Regards, > Kannaiyan > > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > ------------------------------ > > Message: 6 > Date: Tue, 8 May 2007 15:18:42 +0530 > From: "Gaurav Kheterpal" <[EMAIL PROTECTED]> > Subject: Re: [Sip-implementors] Multiple 'm' lines in SDP and > thereinvitebehaviour > To: "'Attila Sipos'" <[EMAIL PROTECTED]>, "'Kannaiyan'" > <[EMAIL PROTECTED]>, <[email protected]> > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="us-ascii" > > Attila, > > I don't think that's true. See inline. > > Regards, > Gaurav > > >1. Is the reinvite of the missing third line is a Violation? > > >No. > >You can specify whatever you like. You can have different > >codecs, ports or even media IP addresses. > > GK>> Yes it is. The RE-INVITE is a violation of RFC 3264 - Section 8.2 which > mentions > > "Existing media streams are removed by creating a new SDP with the port > number for that stream set to zero." > > A "m=" line which is a part of SDP for a request or a response can't be > removed until the call is terminated. Refer to RFC 4317 Example 4.3/ Page 17 > on how to do this (setting port=0). Media types associated with streams can > be changed but m= lines corresponding to media streams can't be removed from > SDP. > > The reason for this is that we need to ensure that it is always possible to > match media sessions (i.e., "m=" lines) in requests and responses. Consider > an INVITE with the following SDP: > > ... > c=IN IP4 1.2.3.4 > m=audio 54678 RTP/AVP 0 1 3 > m=video 7346 RTP/AVP 28 31 (face) > m=video 7880 RTP/AVP 26 28 (presentation) > > > If the response contained something like > > > ... > c=IN IP4 3.4.5.6 > m=audio 6540 RTP/AVP 0 1 > m=video 6578 RTP/AVP 28 > > the caller would not be able to tell which of the two offered video streams > was accepted. > > >2. What response should I send for this? > > I'm not sure what to say except that it's all in RFC3264. I think the most > >important point is that for all m= lines in the offer, there must be a > >corresponding m= line in the answer. > > GK>> I believe it should respond with a 488 - Not Acceptable and Warning > header set to 304. > > > > > ------------------------------ > > Message: 7 > Date: Tue, 8 May 2007 15:26:50 +0530 > From: "Gaurav Kheterpal" <[EMAIL PROTECTED]> > Subject: Re: [Sip-implementors] changing ip during call > To: "'Ishay Cohen'" <[EMAIL PROTECTED]>, > <[email protected]> > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="us-ascii" > > I'm not very sure what you mean by a 'waiting call'. Perhaps you need to > ensure that the un-hold INVITE request has the following attribute: > > a=sendrecv > > instead of a=sendonly or a=recvonly (or a=inactive) > > The same should also be present in the answer. > > Regards, > Gaurav > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:sip-implementors- > > [EMAIL PROTECTED] On Behalf Of Ishay Cohen > > Sent: Tuesday, May 08, 2007 12:45 PM > > To: [email protected] > > Subject: [Sip-implementors] changing ip during call > > > > hi all, > > i tried to change ip during a call and i have some problems: > > i change all headers and address to the new ip and send re-invite... > > what i get is a new call to the receiver (waiting call). > > i try to hold the call and than make un-hold (after i changed the ip) > > and still i get waiting call. > > Is there anything else i can do in order to keep the call after i change > > the ip? > > i tried also registering again and notify but it just "shooting in the > > dark".... help!! :-) > > > > Ishay Cohen > > > > _______________________________________________ > > Sip-implementors mailing list > > [email protected] > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > ------------------------------ > > Message: 8 > Date: Tue, 8 May 2007 12:13:59 +0200 > From: "Christer Holmberg \(JO/LMF\)" <[EMAIL PROTECTED]> > Subject: Re: [Sip-implementors] Multiple 'm' lines in SDP and the > reinvitebehaviour > To: "Rayees Khan" <[EMAIL PROTECTED]>, "Kannaiyan" > <[EMAIL PROTECTED]>, <[email protected]> > Message-ID: > <[EMAIL PROTECTED]> > > Content-Type: text/plain; charset="us-ascii" > > > Hi, > > I think that it is wrong to say that port '0' would simply set a stream > to inactive. Port '0' means that a stream is removed. Yes, you still > need to keep it in the SDP, but all resources associated with it may be > released. > > Regards, > > Christer > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf > > Of Rayees Khan > > Sent: 8. toukokuuta 2007 12:02 > > To: Kannaiyan; [email protected] > > Subject: Re: [Sip-implementors] Multiple 'm' lines in SDP and > > the reinvitebehaviour > > > > > > The re-INVITE is invalid as far as OFFER-ANSWER id concerned. > > A new OFFER should have all the media description of previous > > OFFER and can add new ones. Though by changing port to '0', > > the stream can be set to inactive. > > A server would normally send a 400 response for such request, > > though I am not sure of what warning header it would correspond to. > > > > regards > > Rayees > > > > > > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf > > Of Kannaiyan > > Sent: Tuesday, May 08, 2007 9:33 AM > > To: [email protected] > > Subject: [Sip-implementors] Multiple 'm' lines in SDP and the > > reinvitebehaviour > > > > Hi, > > > > When I offer in the initial invite, > > > > m=audio 3456 RTP/AVP 0 3 4 5 > > m= video 4578 RTP/AVP 98 97 > > m= audio 3487 RTP/AVP 0 3 4 5 > > > > later if I want to reinvite, is it possible to change it to, > > > > m=audio 3456 RTP/AVP 0 3 4 5 > > m= video 4578 RTP/AVP 98 97 > > > > skipping the third line. > > > > 1. Is the reinvite of the missing third line is a Violation? > > 2. What response should I send for this? > > > > Regards, > > Kannaiyan > > > > > > _______________________________________________ > > Sip-implementors mailing list > > [email protected] > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > ______________________________________________________________________ > > This email has been scanned by the MessageLabs Email Security System. > > For more information please visit > > http://www.messagelabs.com/email > > ______________________________________________________________________ > > > > > > > > > > -------------------------------------------------------------- > > -------------------- > > IMPORTANT The information contained in this e-mail any > > attachments is intended only for the named recipient and may > > be privileged or confidential. > > > > If you are not the intended recipient, please notify us > > immediately on +44 (0)1908 425000 and do not disclose, copy, > > distribute or take any action based on the contents of this e-mail. > > > > You should understand and accept that, when communicating > > with us by e-mail, it is not a totally secure communication medium. > > > > We accept no liability for any direct, indirect or > > consequential loss arising from any action taken in reliance > > on the information contained in this e-mail and give no > > warranty or representation as to its accuracy or reliability. > > > > DIGITALK has the facility to monitor and read both incoming > > and outgoing communications by e-mail. In line with industry > > efforts to reduce the proliferation of Un-Solicited SPAM > > messages, DIGITALK uses various methods including Reverse-DNS > > lookups and ban-lists to prevent malicious content reaching our users. > > > > This message and any attachments has been scanned for known > > viruses. However, we would advise you to ensure the content > > is indeed virus free. We do not, to the extent permitted by > > law, accept any liability (whether in contract, negligence or > > otherwise) for any virus infection and/or external compromise > > of security and/or breach of confidentiality in relation to > > transmissions sent by e-mail. > > > > VAT No: GB 876 3287 81. Reg No: 3080801 > > Place of Registration: England > > Registered Office Address: 2 Radian Court, Knowlhill, Milton > > Keynes > > -------------------------------------------------------------- > > --------------------" > > > > > > _______________________________________________ > > 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 > > > End of Sip-implementors Digest, Vol 50, Issue 17 > ************************************************ _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
