[Sip-implementors] Changed From Tag in Spiral Request

Hi All, If a UA receives a request in a spiralled way then shouldn't the >From Tag and Call-ID same as the originated request? Should the UA accept the received request as spiral if call-ID is same and From tag is different? Please let me know if there is any business use case of su

Re: [Sip-implementors] How In early dialog state can UAC send BYE?

One use case is, downstream proxy forks INV and caller would receive multiple 18x response from different callee. Further on receipt of one 2xx response form either of the callee, the other early dialog need to be terminated. In this case, BYE is the appropriate message to be used. ***

[Sip-implementors] Target Refreshing Request

Hi All, Is Notify and Refresh Subscribe a taget refreshing request? Thanks, Manju *** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or ent

Re: [Sip-implementors] Re-invite without To Tag

Tags are part of the dialog match and not trasaction layer. Transaction layer checks for the branch-id and further push the request to TU layer and TU layer performs dialog match where 'To' tag is validated and take decision. So, its TU layer which decides based on 'To' tag. regards, Manju *

Re: [Sip-implementors] Query regarding termination of dialog

Koshy, Suppose UAC sends INVITE and UAS responds with 100 Trying. 1) Now, if UAS wants to terminate the dialog, should it send CANCEL or 487 Request terminated? 2) Similarly, if UAS has send 180 Ringing also and then wants to terminate the dialog, should it send CAN

Re: [Sip-implementors] Call does not go through if ACK is receivedwithContent-Length more than the actual body size

Hi, Please can you put some light on the issue of 200OK: Should I stop the re-transmission of 200OK after getting Wrong ACK or I need to continue? Because after getting ACK even with wrong content-length, state of call is getting changed from completed to confirmed and late

Re: [Sip-implementors] [URGENT] Meaning of the Passage in ScriptSIP_CC_PR_MP_RQ_V_015

Hi Mahesh, Background: RFC 2543 supports strict routing and RFC 3261 supports loose routing. For the backward compatibility for RFC 3261 implementors that line is the guideline. If lr is present in the route header then that entity supports loose routing else strict routing. Thum

Re: [Sip-implementors] query reagrding the branch in VIA

AFAIK, magic cookie is case sensitive and the remaining part is case insensitive because as per ABNF of Via, via-branch is token, so token is case insensitive but the magic cookie ie., "z9hG4bK" is quoted string which is case sensitive. regards, Manju ***

Re: [Sip-implementors] What happens if ACK is never sent for 200 OK

u A B > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Manjunath Warad > Sent: Thursday, December 13, 2007 2:21 PM > To: 'Jitendra Singh Bhadoriya'; Sip-implementors@lists.cs.columbia.edu > Cc: [EMAIL PROTECTED] &g

Re: [Sip-implementors] What happens if ACK is never sent for 200 OK

Hi Jiten, UAS retransmits 2xx response for 64*T1 seconds and within which if it doesn't receive ACK then the session will be terminated, but not the dialog. Hope this helps... regards, Manju *** This e-m

Re: [Sip-implementors] [Sip] To-tag in CANCEL response

Hi Tonny, Please post such queries to sip-implementors at lists.cs.columbia.edu ! Please see inline... *** This e-mail and attachments contain confidenti

Re: [Sip-implementors] Different transport in same call.

In that case UAC MUST support protocol switching also. *** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above.

Re: [Sip-implementors] Different transport in same call.

endra. -Original Message- From: Manjunath Warad [mailto:[EMAIL PROTECTED] Sent: Friday, December 07, 2007 11:31 AM To: Jitendra Singh Bhadoriya; sip-implementors@lists.cs.columbia.edu Cc: [EMAIL PROTECTED] Subject: RE: [Sip-implementors] Different transport in same call. Hi Jiten, A

Re: [Sip-implementors] Different transport in same call.

Hi Jiten, ACK is sent to the contact header of 200INV, and this header is filled by UAS. So, UAC should send ACK on transport specified in the contact header. This will keep up the interoperablity too. regards, Manju **

Re: [Sip-implementors] Difference Between NAT and ALG

Hi, ALG is sip aware component whereas NAT is not. Please correct me if I am wrong. regards, Manju *** This e-mail and attachments contain confidential information from HUAWEI, which is intended only fo

Re: [Sip-implementors] Route-set?

ip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Route-set? One correction. refresh-SUBSCRIBE is a target-refresh request as it can be used to modify the Contact but Route set once established by initial SUBSCRIBE never changes. On Oct 31, 2007 1:07 PM, Manjunath Warad <[EMAIL PROTECTED]>

Re: [Sip-implementors] Route-set?

Hi Anshuman, Neither Notify nor refresh-SUBSCRIBE is considered as target refreshing request, so both cannot update the Route-set. Initial Route-set formed by SUBSCRIBE/200-SUBSCRIBE/NOTIFY MUST be used for subsequent requests. Regards, Manju

Re: [Sip-implementors] Is route set be recomputed while sending ACKfor retransmitted 2xx?

Hi Paul, Are we not exposing private network information by double r-r while proxying request from Private to Public network? I feel this makes system vulnerable to the attackers. regards, Manju *** This

Re: [Sip-implementors] RE-INVITE Problem [packet capture inside]

Hi, I have strong doubt on the SDP that is exchanged in 200 of Re-INVITE. Answerer has added other media formats that he supports and I don't think offerer would support those and hence offerer could be releasing the call by sending ACK and BYE. Regards, Manju *

Re: [Sip-implementors] Question about optional headers in SIP

Hi, I think we have to take call based on the relevance of the header to that particular application. If the header conveys information which is of no relevance then the message can be accepted ignoring that header. If you are worried about the behaviour of underlying "generic sip

Re: [Sip-implementors] URI parameter in To and From headers

Hi Biju, RFC recommends not to add transport param in From and To header. However, if the end-point receives transport param then that param should be ignored. However about creation of responses, if the request is dialog creating then 1. From header is clone as in request, drop