Hi Dear, I have contact China-Post service number 11185 of Shanghai and know the express have been received by the GDNT reception desk in February 2.
The express number is EG586696655CN and you can also check Guangdong china post service number, 11185 to know details. Please contact the reception desk to find the express. Thanks. Any further concern plz let know know when you are free. Have a good day and cheer up! Best Regards, Christina On Mon, Feb 2, 2009 at 9:00 AM, < [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: Misformed ACK causing media session to fail (Brett Tate) > 2. Re: Query related to SDP in 200 OK after UPDATE > (Neelakantan Balasubramanian) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 1 Feb 2009 11:11:06 -0800 > From: Brett Tate <[email protected]> > Subject: Re: [Sip-implementors] Misformed ACK causing media session to > fail > To: Andrew Wood <[email protected]>, > "[email protected]" > <[email protected]> > Message-ID: > <9b2a061a1137254bbe4f4b2cd843646a0f913ee...@mbx02.citservers.local> > Content-Type: text/plain; charset="us-ascii" > > The following are three of the problems: > > 1) The "proxied" 200 has a malformed Contact. > > 2) The "proxied" ACK has an incorrect CSeq since it doesn't match the > "proxied" INVITE's CSeq. > > 3) The request-uri of the ACKs appear incorrect; however it might be > related to problems 1 and 2. > > > -----Original Message----- > > From: [email protected] [mailto:sip- > > [email protected]] On Behalf Of Andrew Wood > > Sent: Sunday, February 01, 2009 7:57 AM > > To: [email protected] > > Subject: [Sip-implementors] Misformed ACK causing media session to fail > > > > The following is a SIP message sequence between two phones and a proxy > > sitting between them > > The Calling phone (201) is on IP 192.168.254.2 > > The called phone (200) is on 192.168.254.1 > > The proxy is on 192.168.254.254 > > > > The phone rings and the caller gets ring tone, and ring tone stops when > > its answered but the media session fails to establish, which I think is > > a problem with the ACK. I think the ACK is being discarded by the called > > phone. > > > > I would be most grateful for any pointers as to what is wrong here. > > > > Thanks > > Andrew > > > > Received INVITE: > > > > INVITE sip:[email protected] <sip%[email protected]>;user=phone > SIP/2.0 > > Via: SIP/2.0/UDP 192.168.254.2:5060;branch=z9hG4bKa87d4e3a87ca634d > > Contact: <sip:[email protected]:5060;user=phone;transport=udp> > > To: <sip:[email protected] <sip%[email protected]>;user=phone> > > From: <sip:[email protected] <sip%[email protected]> > ;user=phone>;tag=3440312132 > > Call-ID: [email protected] > > CSeq: 2 INVITE > > Expires: 300 > > Allow: ACK, BYE, CANCEL, INVITE, NOTIFY, OPTIONS, REFER, REGISTER, > > PRACK, UPDATE > > Content-Type: application/sdp > > Proxy-Authorization: Digest > > > username="userB",realm="",nonce="1233492477:9a4d30a056a8b4aa2afebadffc50ae > > a0",uri="sip:[email protected] <sip%[email protected]> > ",response="37f53e5aff3c049f7564ef00635c60 > > 90",qop=auth-int,nc=00000001,cnonce="bf41afbb" > > > > Supported: replaces, 100rel > > User-Agent: Cisco-CP7912/8.0.0-060111A > > Content-Length: 288 > > > > v=0 > > o=201 805339182 805339182 IN IP4 192.168.254.2 > > s=Cisco 7912 SIP Call > > c=IN IP4 192.168.254.2 > > t=0 0 > > m=audio 16384 RTP/AVP 0 18 8 101 > > a=rtpmap:0 PCMU/8000/1 > > a=rtpmap:18 G729/8000/1 > > a=fmtp:18 annexb=yes > > a=rtpmap:8 PCMA/8000/1 > > a=rtpmap:101 telephone-event/8000 > > a=fmtp:101 0-15 > > > > > > Forwarded INVITE: > > > > > > INVITE sip:[email protected]:5060;user=phone;transport=UDP SIP/2.0 > > Via: SIP/2.0/UDP 192.168.254.2:5060;branch=z9hG4bKa87d4e3a87ca634d > > Max-Forwards: 70 > > Contact: <sip:[email protected]:5060> > > To: <sip:[email protected]:5060;user=phone;transport=UDP> > > From: <sip:[email protected] <sip%[email protected]> > ;user=phone>;tag=3440312132 > > Call-ID: [email protected] > > CSeq: 1 INVITE > > Content-Type: application/sdp > > Content-Length: 288 > > > > v=0 > > o=201 805339182 805339182 IN IP4 192.168.254.2 > > s=Cisco 7912 SIP Call > > c=IN IP4 192.168.254.2 > > t=0 0 > > m=audio 16384 RTP/AVP 0 18 8 101 > > a=rtpmap:0 PCMU/8000/1 > > a=rtpmap:18 G729/8000/1 > > a=fmtp:18 annexb=yes > > a=rtpmap:8 PCMA/8000/1 > > a=rtpmap:101 telephone-event/8000 > > a=fmtp:101 0-15 > > > > > > > > Recieved 180: > > SIP/2.0 180 Ringing > > Via: SIP/2.0/UDP 192.168.254.2:5060;branch=z9hG4bKa87d4e3a87ca634d > > Contact: <sip:[email protected]:5060;user=phone;transport=udp> > > To: <sip:[email protected]:5060;user=phone;transport=UDP>;tag=2081843699 > > From: <sip:[email protected] <sip%[email protected]> > ;user=phone>;tag=3440312132 > > Call-ID: [email protected] > > CSeq: 1 INVITE > > Allow: ACK, BYE, CANCEL, INVITE, NOTIFY, OPTIONS, REFER, REGISTER, > > PRACK, UPDATE > > Server: Cisco-CP7912/8.0.0-060111A > > Content-Length: 0 > > > > > > Forwarded 180: > > SIP/2.0 180 Ringing > > Via: SIP/2.0/UDP 192.168.254.2:5060;branch=z9hG4bKa87d4e3a87ca634d > > Contact: <sip:[email protected]:5060;user=phone;transport=udp> > > To: <sip:[email protected] <sip%[email protected]> > ;user=phone>;tag=2081843699 > > From: <sip:[email protected] <sip%[email protected]> > ;user=phone>;tag=3440312132 > > Call-ID: [email protected] > > CSeq: 2 INVITE > > Allow: ACK, BYE, CANCEL, INVITE, NOTIFY, OPTIONS, REFER, REGISTER, > > PRACK, UPDATE > > Server: Cisco-CP7912/8.0.0-060111A > > Content-Length: 0 > > > > > > > > Recieved 200: > > SIP/2.0 200 OK > > Via: SIP/2.0/UDP 192.168.254.2:5060;branch=z9hG4bKa87d4e3a87ca634d > > Contact: <sip:[email protected]:5060;user=phone;transport=udp> > > To: <sip:[email protected]:5060;user=phone;transport=UDP>;tag=2081843699 > > From: <sip:[email protected] <sip%[email protected]> > ;user=phone>;tag=3440312132 > > Call-ID: [email protected] > > CSeq: 1 INVITE > > Allow: ACK, BYE, CANCEL, INVITE, NOTIFY, OPTIONS, REFER, REGISTER, > > PRACK, UPDATE > > Content-Type: application/sdp > > Server: Cisco-CP7912/8.0.0-060111A > > Supported: replaces > > Content-Length: 210 > > > > v=0 > > o=200 42059188 42059188 IN IP4 192.168.254.1 > > s=Cisco 7912 SIP Call > > c=IN IP4 192.168.254.1 > > t=0 0 > > m=audio 16384 RTP/AVP 0 101 > > a=rtpmap:0 PCMU/8000/1 > > a=rtpmap:101 telephone-event/8000 > > a=fmtp:101 0-15 > > > > > > Forwarded 200: > > SIP/2.0 200 OK > > Via: SIP/2.0/UDP 192.168.254.2:5060;branch=z9hG4bKa87d4e3a87ca634d > > Contact: <sip:> > > To: <sip:[email protected] <sip%[email protected]> > ;user=phone>;tag=2081843699 > > From: <sip:[email protected] <sip%[email protected]> > ;user=phone>;tag=3440312132 > > Call-ID: [email protected] > > CSeq: 2 INVITE > > Content-Type: application/sdp > > Content-Length: 210 > > > > v=0 > > o=200 42059188 42059188 IN IP4 192.168.254.1 > > s=Cisco 7912 SIP Call > > c=IN IP4 192.168.254.1 > > t=0 0 > > m=audio 16384 RTP/AVP 0 101 > > a=rtpmap:0 PCMU/8000/1 > > a=rtpmap:101 telephone-event/8000 > > a=fmtp:101 0-15 > > setting tcsid = 379 > > > > > > > > Received ACK : > > > > ACK sip:192.168.254.254 SIP/2.0 > > Via: SIP/2.0/UDP 192.168.254.2:5060;branch=z9hG4bKf5d124862f8aad9a > > To: <sip:[email protected] <sip%[email protected]> > ;user=phone>;tag=2081843699 > > From: <sip:[email protected] <sip%[email protected]> > ;user=phone>;tag=3440312132 > > Call-ID: [email protected] > > CSeq: 2 ACK > > Proxy-Authorization: Digest > > > username="userB",realm="",nonce="1233492477:9a4d30a056a8b4aa2afebadffc50ae > > a0",uri="sip:[email protected] <sip%[email protected]> > ",response="37f53e5aff3c049f7564ef00635c60 > > 90",qop=auth-int,nc=00000001,cnonce="bf41afbb" > > User-Agent: Cisco-CP7912/8.0.0-060111A > > Content-Length: 0 > > > > > > > > Forwarded ACK: > > ACK sip:[email protected] <sip%[email protected]>;user=phone > SIP/2.0 > > Via: SIP/2.0/UDP 192.168.254.2:5060;branch=z9hG4bKf5d124862f8aad9a > > To: <sip:[email protected] <sip%[email protected]> > ;user=phone>;tag=2081843699 > > From: <sip:[email protected] <sip%[email protected]> > ;user=phone>;tag=3440312132 > > Call-ID: [email protected] > > CSeq: 2 ACK > > Proxy-Authorization: Digest > > > username="userB",realm="",nonce="1233492477:9a4d30a056a8b4aa2afebadffc50ae > > a0",uri="sip:[email protected] <sip%[email protected]> > ",response="37f53e5aff3c049f7564ef00635c60 > > 90",qop=auth-int,nc=00000001,cnonce="bf41afbb" > > User-Agent: Cisco-CP7912/8.0.0-060111A > > Content-Length: 0 > > > > _______________________________________________ > > Sip-implementors mailing list > > [email protected] > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > ------------------------------ > > Message: 2 > Date: Mon, 2 Feb 2009 08:20:58 -0800 > From: Neelakantan Balasubramanian <[email protected]> > Subject: Re: [Sip-implementors] Query related to SDP in 200 OK after > UPDATE > To: Subbu Rajendran <[email protected]>, Nebojsa Miljanovic > <[email protected]> > Cc: "[email protected]" > <[email protected]> > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="us-ascii" > > See below. > > > > -----Original Message----- > > From: [email protected] [mailto:sip- > > [email protected]] On Behalf Of Subbu > > Rajendran > > Sent: Sunday, February 01, 2009 7:29 AM > > To: Nebojsa Miljanovic > > Cc: [email protected] > > Subject: Re: [Sip-implementors] Query related to SDP in 200 OK after > > UPDATE > > > > Hi, > > Thanks all for the response to my query. And sorry for delaying this > > email. > > The draft that Neb had mentioned in the email had the answers to my > > query > > (The example in section 3.1.1). > > > > I suppose the following two are acceptable UAS behavior in this case: > > 1. If the offer answer is completed for an INVITE transaction, i.e. > > when > > answer to the offer is send in reliable response (180 Ringing with > > 100rel > > option), then the 200 OK for INVITE should not echo the answer SDP. > [Neel] > In this case, the 200 OK MUST contain the same answer SDP as that of 180 > Ringing. > > > > > 2. However if the 200 OK for INVITE has SDP it MUST be the last > > answer > > SDP (no offer can be initiated). This way there shall be no impact to > > the > > media session if the UAC honors the SDP in the 200 OK for INVITE or > > even if > > it ignores it. > > > [Neel] > There is no last answer. For each offer, there is only one answer for the > same endpoint. > > > Thanks & Regards, > > Subbu > > > > On Wed, Jan 21, 2009 at 2:29 AM, Nebojsa Miljanovic > > <[email protected]>wrote: > > > > > Subbu, > > > take a look at the following draft that talks about it. > > > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip- > > offeranswer-10.txt > > > > > > Section 3.1.1 states that if you are UAS, you should not send any SDP > > in > > > 2xx but > > > if you are UAC, be ready to ignore it. In other words, don't kill a > > call if > > > it > > > is there. > > > > > > Unfortunate reality is that many endpoints are hardcoded to expect > > SDP in > > > 2xx > > > even if offer/answer is fully done. And, they end up killing the call > > if no > > > SDP > > > is present in 2xx. > > > > > > Neb > > > > > > On 1/20/2009 1:30 AM, Subbu Rajendran wrote: > > > > Hi All, > > > > Following is example call flow from RFC 3311 (SIP UPDATE Method). > > Is SDP > > > a > > > > must in the 200 OK for INVITE in this case? If it is required, then > > 200 > > > OK > > > > should contain 'answer 3'. Is this a legal behavior as answer in > > 200 OK > > > for > > > > INVITE ('answer 3') is not based on the offer in the INVITE ('offer > > 1'). > > > > > > > > Could anyone please explain or point me to the RFC that explains > > this > > > case? > > > > > > > > Caller Callee > > > > > > > > (1) INVITE with offer 1 > > > > |---------------------------->| > > > > > > > > (2) 180 with answer 1 > > > > |<----------------------------| > > > > > > > > (3) PRACK > > > > |---------------------------->| > > > > > > > > (4) 200 PRACK > > > > |<----------------------------| > > > > > > > > (5) UPDATE with offer 2 > > > > |---------------------------->| > > > > > > > > (6) 200 UPDATE with answer 2 > > > > |<----------------------------| > > > > > > > > (7) UPDATE with offer 3 > > > > |<----------------------------| > > > > > > > > (8) 200 UPDATE with answer 3 > > > > |---------------------------->| > > > > > > > > (9) 200 INVITE (SDP ?) > > > > |<----------------------------| > > > > > > > > (10) ACK > > > > |---------------------------->| > > > > > > > > > > > > Thanks & Regards, > > > > Subbu > > > > _______________________________________________ > > > > 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 > > > > ------------------------------ > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > End of Sip-implementors Digest, Vol 71, Issue 2 > *********************************************** > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
