Hi,
I am new to this group. Need some info on 1. what is call-mapping in SIP. 2.How to implement it. nishant On 21 July 2010 15:07, <[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. Re: How sip stack can recover from the followingerror > condition..... (Harbhanu) > 2. Port not present in registration bindings (Aman Aggarwal) > 3. Re: Port not present in registration bindings (I?aki Baz Castillo) > 4. retransmission of 180Ringing with require: 100rel (Peter Nijhuis) > 5. retransmission of 180Ringing with require: 100rel (Peter Nijhuis) > 6. Re: retransmission of 180Ringing with require: 100rel > ($...@r\/|>r!`/@) > 7. Re: retransmission of 180Ringing with require: 100rel > (I?aki Baz Castillo) > 8. Re: retransmission of 180Ringing with require: 100rel > (Peter Nijhuis) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 15 Jul 2010 18:43:19 +0530 > From: Harbhanu <[email protected]> > Subject: Re: [Sip-implementors] How sip stack can recover from the > followingerror condition..... > To: "'radhakrishna'" <[email protected]>, "'Pandurangan R S'" > <[email protected]> > Cc: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=iso-8859-1 > > > >> How about adding a new header something like "Remort-CSeq: 10000" in 500 > >> response? > > There are two possible issues with this - > 1. Attacker can sniff the response and change it to the valid value of Cseq > at UAC, thus leading to call drop. > 2. Attacker can now join-in within any arbitrary CSeq, coz we will offer > the > valid CSeq to be used. > > As already pointed our, IMO too by doing this we will just try to re-invent > the wheel eventually, instead of borrowing the learnings from existing > solutions in network such as one in internet. > > > **************************************************************************** > *********** > This e-mail and 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 > radhakrishna > Sent: Thursday, July 15, 2010 8:12 AM > To: 'Pandurangan R S' > Cc: [email protected] > Subject: Re: [Sip-implementors] How sip stack can recover from the > followingerror condition..... > > How about adding a new header something like "Remort-CSeq: 10000" in 500 > response? > UAC can understand that the he has to increase the CSeq value to more than > 10000 and can recover easily? > > Regards, > RadhaKrishna > > > -----Original Message----- > From: Pandurangan R S [mailto:[email protected]] > Sent: Thursday, July 15, 2010 7:34 AM > To: radhakrishna > Cc: [email protected] > Subject: Re: [Sip-implementors] How sip stack can recover from the > followingerror condition..... > > If the attacker is able to sniff and inject messages into the channel, > then there are wide variety of attacks possible, as Brett has already > indicated. So it is recommended to secure the channel using TLS or > anything as such. > > Another possible attack is attacker can inject responses once he > sniffs the request and the responses cannot be authenticated. > > So securing the channel is a recommended way to thwart these kind of > attacks. > > > > We suggest that RFC should have a way to convey the CSEQ value stored by > UAS > > in 500 response message so that UAC can come out of the loop. > > Nothing prevents the attacker from using a CSEQ of 2^32-1 (maximum > possible value) > > On Wed, Jul 14, 2010 at 2:01 PM, radhakrishna <[email protected]> > wrote: > > Dear All, > > > > > > > > I want to know if there is any way to come out of the following problem. > > > > > > > > UAC ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? UAS > > > > ----------------------------INV (CSEQ: 1) ------------------------> > > > > <---------------------------200 OK---------------------------------- > > > > ----------------------------ACK ------------------------------------> > > > > > > > > ? ? ? ? ? ?Attacker > > > > ? ? ? ? ? ?----------------Update (CSEQ: 10000) ----------> > > > > ? ? ? ? ? ?<------------------- 401/407 ------------------------------ > > > > > > > > -----------------------UPDATE (CSEQ: 2) ------------------> > > > > <----------------------- 500 -------------------------------------- > > > > > > > > Now since the actual UAC is not aware of the attacker, he will keep > > incrementing the CSEQ every time and will try to send the request. The > > request would be successful only after trying for some 9999 times. How do > we > > overcome this kind of situation? > > > > > > > > We suggest that RFC should have a way to convey the CSEQ value stored by > UAS > > in 500 response message so that UAC can come out of the loop. > > > > Can anyone please share your opinion on this issue? > > > > > > > > Regards, > > > > RadhaKrishna > > > > > > > > > > > > > > > > _______________________________________________ > > 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: 2 > Date: Sat, 17 Jul 2010 17:14:18 +0530 > From: Aman Aggarwal <[email protected]> > Subject: [Sip-implementors] Port not present in registration bindings > To: "[email protected]" > <[email protected]> > Message-ID: > < > df735188ed91bd458fa0e0c17929339f86a89...@gurexmb01.asian.ad.aricent.com> > > Content-Type: text/plain; charset="us-ascii" > > Hi All, > > Should UAC assumes port =5060 for a binding received in Contact header of > 200 OK response for REGISTER if it does not contain port? For e.g. > > UAC sends Contact header in REGISTER:- > > Contact: <sip: [email protected]:5060>;expires=100 > UAC receives Contact header in 200 OK response:- > Contact: <sip:[email protected] <sip%[email protected]>>;expires=100, > <sip:[email protected]:5062>;expires=10 > > Now, while matching for correct binding, should UAC assumes port=5060 for > first binding in Contact header of 200 OK or treat it as a failure? > > > Thanks and regards, > > Aman Aggarwal > Aricent > > ________________________________ > "DISCLAIMER: This message is proprietary to Aricent and is intended solely > for the use of the individual to whom it is addressed. It may contain > privileged or confidential information and should not be circulated or used > for any purpose other than for what it is intended. If you have received > this message in error, please notify the originator immediately. If you are > not the intended recipient, you are notified that you are strictly > prohibited from using, copying, altering, or disclosing the contents of this > message. Aricent accepts no responsibility for loss or damage arising from > the use of the information transmitted by this email including damage from > virus." > > > ------------------------------ > > Message: 3 > Date: Sat, 17 Jul 2010 19:39:46 +0200 > From: I?aki Baz Castillo <[email protected]> > Subject: Re: [Sip-implementors] Port not present in registration > bindings > To: Aman Aggarwal <[email protected]> > Cc: "[email protected]" > <[email protected]> > Message-ID: > <[email protected]> > Content-Type: text/plain; charset=UTF-8 > > 2010/7/17 Aman Aggarwal <[email protected]>: > > Hi All, > > > > Should UAC assumes port =5060 for a binding received in Contact header of > 200 OK response for REGISTER if it does not contain port? For e.g. > > > > UAC sends Contact header in REGISTER:- > > > > Contact: <sip: [email protected]:5060>;expires=100 > > UAC receives Contact header in 200 OK response:- > > Contact: <sip:[email protected] <sip%[email protected]>>;expires=100, > <sip:[email protected]:5062>;expires=10 > > > > Now, while matching for correct binding, should UAC assumes port=5060 for > first binding in Contact header of 200 OK or treat it as a failure? > > > RFC 3261 - 19.1.4 URI Comparison: > > ------------------------------------ > A URI omitting any component with a default value will not > match a URI explicitly containing that component with its > default value. For instance, a URI omitting the optional port > component will not match a URI explicitly declaring port 5060. > The same is true for the transport-parameter, ttl-parameter, > user-parameter, and method components. > ------------------------------------ > > > So technically speaking the response for your question is "no": these > URI's don't match. > > However, a SIP URI having an IP as host part it's the same as such SIP > URI with port 5060 (this is not true if the host part would be a > domain/hostname). Anyhow I think that section 19.1.4 has priority. > > > -- > I?aki Baz Castillo > <[email protected]> > > > > ------------------------------ > > Message: 4 > Date: Wed, 21 Jul 2010 09:42:12 +0200 > From: "Peter Nijhuis" <[email protected]> > Subject: [Sip-implementors] retransmission of 180Ringing with require: > 100rel > To: <[email protected]> > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > Hello All, > > > > I'm facing the following problem: > > > > An incoming call is first ringing on a call center queue: > > The UAS is sending a 180 Ringing with SDP and a require: 100rel, the UAC > responds with a PRACK and the UAS again with an 200 OK. > > > > Then the call is actually ringing on a UA (IP hardphone) > > The UAS send a 180 Ringing again with an SDP and a require:100rel, but the > UAC ignores this as is seems a duplicate message. > > > > > > ? INVITE/SDP supported: 100rel > > 100 Trying ? > > 180 Ringing/SDP ? > > Require: 100rel RSeq:1 > > ? PRACK > > 200 OK ? > > 180 Ringing/SDP ? > > Require: 100rel RSeq:2 > > 180 Ringing/SDP ? > > Require: 100rel RSeq:2 > > > > 180 Ringing/SDP ? > > Require: 100rel RSeq:2 > > > > 180 Ringing/SDP ? > > Require: 100rel RSeq:2 > > > > 180 Ringing/SDP ? > > Require: 100rel RSeq:2 > > > > > > Is the UAS allowed to send multiple 180 Ringing with a require header > field? > > > > Best Regards, > > > > Peter Nijhuis > > Technisch Consultant > > > > Televersal Group > > Bezoekadres: Nedervonder 19, 5061 JP, Oisterwijk > > Postadres: Postbus 37, 5066 ZG, Moergestel > > T: +31 13 523 11 89 | F: +31 13 523 11 88 > > I: www.televersalgroup.com <http://www.televersalgroup.com> | E: > [email protected] > > > > > > > > ------------------------------ > > Message: 5 > Date: Wed, 21 Jul 2010 09:50:54 +0200 > From: "Peter Nijhuis" <[email protected]> > Subject: [Sip-implementors] retransmission of 180Ringing with require: > 100rel > To: <[email protected]> > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="us-ascii" > > Hello All, > > I'm facing the following problem: > > An incoming call is first ringing on a call center queue: > The UAS is sending a 180 Ringing with SDP and a require: 100rel, the UAC > responds with a PRACK and the UAS again with an 200 OK. > > Then the call is actually ringing on a UA (IP hardphone) > The UAS send a 180 Ringing again with an SDP and a require:100rel, but > the UAC ignores this as is seems a duplicate message. > > > <-- > INVITE/SDP supported: 100rel > > 100 Trying --> > > 180 Ringing/SDP --> > Require: 100rel RSeq:1 > <-- PRACK > > > 200 OK --> > > 180 Ringing/SDP --> > Require: 100rel RSeq:2 > > 180 Ringing/SDP --> > Require: 100rel RSeq:2 > > 180 Ringing/SDP --> > Require: 100rel RSeq:2 > > 180 Ringing/SDP --> > Require: 100rel RSeq:2 > > 180 Ringing/SDP --> > Require: 100rel RSeq:2 > > > Is the UAS allowed to send multiple 180 Ringing with a require header > field? > > Best Regards, > > Peter Nijhuis > > > > > > ------------------------------ > > Message: 6 > Date: Wed, 21 Jul 2010 14:12:21 +0530 > From: "$...@r\\/|>r!`/@" <[email protected]> > Subject: Re: [Sip-implementors] retransmission of 180Ringing with > require: 100rel > To: Peter Nijhuis <[email protected]> > Cc: [email protected] > Message-ID: > <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi Peter, > > RFC 3262 for UAS section 3 clearly says > "After the first reliable provisional response for a request has been > acknowledged, > the UAS MAY send additional reliable provisional responses. The UAS MUST > NOT > send a second reliable provisional response until the first is > acknowledged. > After the first, it is RECOMMENDED that the UAS not send an additional > reliable provisional response until the previous is acknowledged. The first > reliable provisional response receives special treatment because it conveys > the > initial sequence number. If additional reliable provisional responses were > sent before the first was acknowledged, the UAS could not be certain these > were received in order." > > For UAC behavior section 4 says > " Handling of subsequent reliable provisional responses for the same > initial > request follows the same rules as above, with the following difference: > reliable provisional responses are guaranteed to be in order. As a result, > if the UAC receives another reliable provisional response to the same > request, and its RSeq value is not one higher than the value of the > sequence > number, that response MUST NOT be acknowledged with a PRACK, and MUST NOT > be > processed further by the UAC. An implementation MAY discard the response, > or > MAY cache the response in the hopes of receiving the missing responses.The > UAC MAY acknowledge reliable provisional responses received after the final > response or MAY discard them." > > But for sure it increases the traffic. > > On Wed, Jul 21, 2010 at 1:20 PM, Peter Nijhuis < > [email protected]> wrote: > > > Hello All, > > > > I'm facing the following problem: > > > > An incoming call is first ringing on a call center queue: > > The UAS is sending a 180 Ringing with SDP and a require: 100rel, the UAC > > responds with a PRACK and the UAS again with an 200 OK. > > > > Then the call is actually ringing on a UA (IP hardphone) > > The UAS send a 180 Ringing again with an SDP and a require:100rel, but > > the UAC ignores this as is seems a duplicate message. > > > > > > <-- > > INVITE/SDP supported: 100rel > > > > 100 Trying --> > > > > 180 Ringing/SDP --> > > Require: 100rel RSeq:1 > > <-- PRACK > > > > > > 200 OK --> > > > > 180 Ringing/SDP --> > > Require: 100rel RSeq:2 > > > > 180 Ringing/SDP --> > > Require: 100rel RSeq:2 > > > > 180 Ringing/SDP --> > > Require: 100rel RSeq:2 > > > > 180 Ringing/SDP --> > > Require: 100rel RSeq:2 > > > > 180 Ringing/SDP --> > > Require: 100rel RSeq:2 > > > > > > Is the UAS allowed to send multiple 180 Ringing with a require header > > field? > > > > Best Regards, > > > > Peter Nijhuis > > > > > > > > _______________________________________________ > > Sip-implementors mailing list > > [email protected] > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > > > -- > cheers!!!! > sarvpriya > > > ------------------------------ > > Message: 7 > Date: Wed, 21 Jul 2010 11:27:00 +0200 > From: I?aki Baz Castillo <[email protected]> > Subject: Re: [Sip-implementors] retransmission of 180Ringing with > require: 100rel > To: "$...@r\\/|>r!`/@" <[email protected]> > Cc: [email protected] > Message-ID: > <[email protected]> > Content-Type: text/plain; charset=UTF-8 > > 2010/7/21 $...@r\/|>r!`/@ <[email protected]>: > > > For UAC behavior section 4 says > > " Handling of subsequent reliable provisional responses for the same > initial > > request follows the same rules as above, with the following difference: > > reliable provisional responses are guaranteed to be in order. As a > result, > > if the UAC receives another reliable provisional response to the same > > request, and its RSeq value is not one higher than the value of the > sequence > > number, that response MUST NOT be acknowledged with a PRACK, and MUST NOT > be > > processed further by the UAC. An implementation MAY discard the response, > or > > MAY cache the response in the hopes of receiving the missing > responses.The > > UAC MAY acknowledge reliable provisional responses received after the > final > > response or MAY discard them." > > But in the given case the UAS sends a new reliable response with RSeq > + 1 after the first one (RSeq=1) is acknowledged, so the UAC should > send a PRACK, am I right? > > > -- > I?aki Baz Castillo > <[email protected]> > > > > ------------------------------ > > Message: 8 > Date: Wed, 21 Jul 2010 11:33:24 +0200 > From: "Peter Nijhuis" <[email protected]> > Subject: Re: [Sip-implementors] retransmission of 180Ringing with > require: 100rel > To: "$...@r\\/|>r!`/@" <[email protected]> > Cc: [email protected] > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > Hi Sarvpriya, > > Thanks for your quick responding > > So when it understand it right, > - The UAS MAY send the 180 ringing with require header since > the Rseq is incremented by 1 and the first reliable provisional response has > been acknowledged. > - The UAC MUST respond with an PRACK. > > Best regards, > > Peter Nijhuis > Technisch Consultant > > Televersal Group > Bezoekadres: Nedervonder 19, 5061 JP, Oisterwijk > Postadres: Postbus 37, 5066 ZG, Moergestel > T: +31 13 523 11 89 | F: +31 13 523 11 88 > I: www.televersalgroup.com | E: [email protected] > > ============================================================================================================= > > > Van: $...@r\/|>r!`/@ [mailto:[email protected]] > Verzonden: woensdag 21 juli 2010 10:42 > Aan: Peter Nijhuis > CC: [email protected] > Onderwerp: Re: [Sip-implementors] retransmission of 180Ringing with > require: 100rel > > Hi Peter, > > RFC 3262 for UAS section 3 clearly says > "After the first reliable provisional response for a request has been > acknowledged, the UAS MAY send additional reliable provisional responses. > The UAS MUST NOT send a second reliable provisional response until the first > is acknowledged. After the first, it is RECOMMENDED that the UAS not send an > additional reliable provisional response until the previous is acknowledged. > The first reliable provisional response receives special treatment because > it conveys the initial sequence number. If additional reliable provisional > responses were sent before the first was acknowledged, the UAS could?not be > certain these were received in order." > > For UAC behavior section 4 says > " Handling of subsequent reliable provisional responses for the same > initial request follows the same rules as above, with the following > difference: reliable provisional responses are guaranteed to be in order. As > a result, if the UAC receives another reliable provisional response to the > same request, and its RSeq value is not one higher than the value of the > sequence number, that response MUST NOT be acknowledged with a PRACK, and > MUST NOT be processed further by the UAC. An implementation MAY discard the > response, or MAY cache the response in the hopes of receiving the missing > responses.The UAC MAY acknowledge reliable provisional responses received > after the final response or MAY discard them." > > But for sure it increases the traffic. > > On Wed, Jul 21, 2010 at 1:20 PM, Peter Nijhuis < > [email protected]> wrote: > Hello All, > > I'm facing the following problem: > > An incoming call is first ringing on a call center queue: > The UAS is sending a 180 Ringing with SDP and a require: 100rel, the UAC > responds with a PRACK and the UAS again with an 200 OK. > > Then the call is actually ringing on a UA (IP hardphone) > The UAS send a 180 Ringing again with an SDP and a require:100rel, but > the UAC ignores this as is seems a duplicate message. > > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?<-- > INVITE/SDP supported: 100rel > > 100 Trying ? ? ? ? ? ? ? ? ? ?--> > > 180 Ringing/SDP ? ? ? ? ? ? ? --> > Require: 100rel RSeq:1 > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?<-- ? ? ? ? ? ? ? ? ? ? PRACK > > > 200 OK ? ? ? ? ? ? ? ? ? ? ? ? ?--> > > 180 Ringing/SDP ? ? ? ? ? ? ? ? --> > Require: 100rel RSeq:2 > > 180 Ringing/SDP ? ? ? ? ? ? ? ? --> > Require: 100rel RSeq:2 > > 180 Ringing/SDP ? ? ? ? ? ? ? ? --> > Require: 100rel RSeq:2 > > 180 Ringing/SDP ? ? ? ? ? ? ? ? --> > Require: 100rel RSeq:2 > > 180 Ringing/SDP ? ? ? ? ? ? ? ? --> > Require: 100rel RSeq:2 > > > Is the UAS allowed to send multiple 180 Ringing with a require header > field? > > Best Regards, > > Peter Nijhuis > > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > -- > cheers!!!! > sarvpriya > > > > ------------------------------ > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > End of Sip-implementors Digest, Vol 88, Issue 12 > ************************************************ > -- The history of the world is the history of few men who had faith in themselves...... _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
