Re: [Sip-implementors] Query on SIM swap

thank you Paul for guidance Regards Ranjit On Tue, May 12, 2020 at 8:13 AM Paul Kyzivat wrote: > Since this discussion seems to be specific to 3gpp use of SIP I suggest > you continue this discussion in some 3gpp-specific forum. > > On 5/11/20 7:50 PM, ankur bansal wrote: > > Hi Ranjit > > > >

Re: [Sip-implementors] Query on SIM swap

Since this discussion seems to be specific to 3gpp use of SIP I suggest you continue this discussion in some 3gpp-specific forum. On 5/11/20 7:50 PM, ankur bansal wrote: Hi Ranjit There is no clear specification saying UE should deregister when SIM is removed . But if refer multiple specs , we

Re: [Sip-implementors] Query on SIM swap

Hi Ranjit There is no clear specification saying UE should deregister when SIM is removed . But if refer multiple specs , we can reach a point where UE supposed to do it . As per 3gpp 24.301 5.5.2.1 General *The detach procedure with appropriate detach type shall be invoked by the UE* if the UE

Re: [Sip-implementors] Query on SIM swap

Thank you Dale. as part of SIM swap testing, I came across the below scenario: the Phone number (MSISDN-1) was registered with IMSI (IMSI-1). when SIM Swap occurred, the INVITE came with a different IMSI and CSCF sends diameter SAR with "Unregistered user". But HSS thinks user is registered and s

Re: [Sip-implementors] Query on SIM swap

Ranjit Avasarala writes: > Does SIM swap procedure on a SIP UE trigger re-registration? if not when > calls are made from the device, the INVITE would have the IMSI of the new > SIM card? The answers aren't set by the SIP standards. However, given that the SIM gives the Directory Number of a PS

[Sip-implementors] Query on SIM swap

Hi Does SIM swap procedure on a SIP UE trigger re-registration? if not when calls are made from the device, the INVITE would have the IMSI of the new SIM card? Thank you Ranjit ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu htt

Re: [Sip-implementors] Query on 500 Server Internal Error

Have you seen RFC3326? It might be just what you are looking for and I know at least a few implementations that support it to various extent. -Max On Tue, Apr 28, 2020 at 2:01 PM Ranjit Avasarala wrote: > Hi SIP Experts > > there are numerous scenarios where a SIP server would respond with 500

[Sip-implementors] Query on 500 Server Internal Error

Hi SIP Experts there are numerous scenarios where a SIP server would respond with 500 Internal Server Error response. Troubleshooting the 500 error is not easy due to the lack of any reason in the response though some servers do append Reason header. e.g. 500 Internal Server Error ...

Re: [Sip-implementors] Query on SIP 488 response

Thank you Paul. So the terminating device can send 488 with SDP - though that functionality is not present. On Sun, Dec 15, 2019 at 1:13 PM Paul Kyzivat wrote: > On 12/15/19 12:31 AM, Ranjit Avasarala wrote: > > Hi > > I have a scenario where the terminating device responds with SIP 488 Not > >

Re: [Sip-implementors] Query on SIP 488 response

On 12/15/19 12:31 AM, Ranjit Avasarala wrote: Hi I have a scenario where the terminating device responds with SIP 488 Not Acceptable here response. It is understood that the terminating device does not support any of the codecs that the incoming INVITE has. this issue occurred when a landline c

Re: [Sip-implementors] Query on SIP 488 response

Isn't this what late offers are meant to accomplish? Empty (no SDP) INVITE --> <-- 200 OK with SDP offer end-to-end ACK with SDP answer --> -- Alex On Sat, Dec 14, 2019 at 11:31:50PM -0600, Ranjit Avasarala wrote: > Hi > I have a scenario where the terminating device responds with SIP

[Sip-implementors] Query on SIP 488 response

Hi I have a scenario where the terminating device responds with SIP 488 Not Acceptable here response. It is understood that the terminating device does not support any of the codecs that the incoming INVITE has. this issue occurred when a landline called VoLTE device and the intermediate MSC/MGCF

Re: [Sip-implementors] Query regarding fallback to media after Fax

On 9/20/19 12:49 AM, Rohit Jain wrote: Hi All, I have a query that can a SIP device fallback from fax to audio again. Following is the scenario: User initiated a call with audio and call is connected. After this user sent a ReInvite with t38 fax and both offer answer are negotiated. Can a use

Re: [Sip-implementors] Query regarding fallback to media after Fax

It is perfectly fine to Re-Invite to an audio conversation after transmitting data. But this is actually only relevant when you are talking to somebody, then transmit data and talk again. When this session is only established to transmit data you can end the session after data transmission is fini

[Sip-implementors] Query regarding fallback to media after Fax

Hi All, I have a query that can a SIP device fallback from fax to audio again. Following is the scenario: User initiated a call with audio and call is connected. After this user sent a ReInvite with t38 fax and both offer answer are negotiated. Can a user again send ReInvite with audio, or afte

[Sip-implementors] Query freelance SIP & C & Embedded OSs

Hi, not sure if the list is used for this purpose or not. If it does not follow the list ettiquette, please let me know and I will not post this type of messages. Otherwise, any input about the below will be appreciated. Additionally, if you know about alternative distribution lists whose members

Re: [Sip-implementors] Query about Content-Type when Content-Length = 0

To follow up to Paul's message, the situation of an empty and/or missing body is not well-specified in SIP, and a SIP parser should be careful to "be liberal in what you accept". In particular, if the observed or specified content length is zero, it *might* be that there is no body, or it *might*

Re: [Sip-implementors] Query about Content-Type when Content-Length = 0

On 12/7/18 5:12 AM, Hamza Mohamed Salman wrote: Dear, Good Day. The trace result shows that The 480 arrives to the node, and it is rejected (dropped) because there is a fault in the message. The following is seen in the communication buffer of the TEST SYSTEM trace we receive yesterday. SIP/

Re: [Sip-implementors] Query about Content-Type when Content-Length = 0

Dear, Good Day. The trace result shows that The 480 arrives to the node, and it is rejected (dropped) because there is a fault in the message. The following is seen in the communication buffer of the TEST SYSTEM trace we receive yesterday. SIP/2.0 480 Temporarily Unavailable Via: SIP/2.0/UDP

Re: [Sip-implementors] Query on SIP REGISTER refresh dialog

On 3/10/17 2:49 PM, Dale R. Worley wrote: Puneet Kumar writes: If a UA uses different dialog-ID(say new Call-ID & No To header tag) for REGISTER refresh with same contact address then it is allowed? If not then please point out RFC section which blocks a UA from doing it. In general does REGIS

Re: [Sip-implementors] Query on SIP REGISTER refresh dialog

Puneet Kumar writes: > If a UA uses different dialog-ID(say new Call-ID & No To header tag) > for REGISTER refresh with same contact address then it is allowed? > If not then please point out RFC section which blocks a UA from doing it. > > In general does REGISTER refresh & REGISTER for deregistr

Re: [Sip-implementors] Query on SIP REGISTER refresh dialog

neet Kumar'; 'sip-implementors@lists.cs.columbia.edu' > Subject: RE: [Sip-implementors] Query on SIP REGISTER refresh dialog > > > If a UA uses different dialog-ID (say new Call-ID & No To header tag) > > for REGISTER refresh with same contact address then it is allowed

Re: [Sip-implementors] Query on SIP REGISTER refresh dialog

> If a UA uses different dialog-ID (say new Call-ID & No To > header tag) for REGISTER refresh with same contact > address then it is allowed? Yes; however you should read RFC 3261 section 10. For instance, section 10.2.4 indicates "UA SHOULD use the same Call-ID for all registrations during a si

[Sip-implementors] Query on SIP REGISTER refresh dialog

Hi All, I have a generic doubt on SIP registration request. If a UA uses different dialog-ID(say new Call-ID & No To header tag) for REGISTER refresh with same contact address then it is allowed? If not then please point out RFC section which blocks a UA from doing it. In general does REGISTER

Re: [Sip-implementors] Query regarding

Rohit Jain writes: > I have a customer that has A PBX that sends a 200 OK with a 200 OK with the > PAI Header (with CRLF on two lines): > > P-Asserted-Identity: "Blumenberger Jr > n" > > instead of > > P-Asserted-Identity: "Blumenberger > Jrene It appears that your examples were damaged in tran

Re: [Sip-implementors] Query regarding

> I have a customer that has A PBX that sends a 200 OK with > a 200 OK with the PAI Header (with CRLF on two lines): > Is this type of header correct as per RFC ? Since your "instead of" example also appeared to have an extra CRLF (and was missing a quote), I couldn't determine from your exampl

Re: [Sip-implementors] Query regarding

Hi Rohit, As per your description, I understand that PAI header is received in multiple lines. Please refer RFC-3261, section 7.3.1 Header Field Format to check whether your header format is correct. Hope you will get the fix. Thanks, Alok On Mon, Feb 27, 2017 at 12:37 PM, Rohit Jain wrote:

[Sip-implementors] Query regarding

Hi, I have a customer that has A PBX that sends a 200 OK with a 200 OK with the PAI Header (with CRLF on two lines): P-Asserted-Identity: "Blumenberger Jr n" instead of P-Asserted-Identity: "Blumenberger Jrene Is this type of header correct as per RFC ? I need a definitive answer if a SBC

Re: [Sip-implementors] Query on UAS sending 200 for INVITE before it receives a 200 for an UPDATE it sent

e R. Worley [mailto:wor...@ariadne.com] > Sent: 14 September 2016 16:56 > To: Harrison, Jason, Vodafone UK > Cc: sip-implementors@lists.cs.columbia.edu > Subject: Re: [Sip-implementors] Query on UAS sending 200 for INVITE before > it receives a 200 for an UPDATE it sent > > W

Re: [Sip-implementors] Query on UAS sending 200 for INVITE before it receives a 200 for an UPDATE it sent

Paul Kyzivat writes: > There is no *general* requirement that there be only one > transaction at a time within a dialog, and in fact there are many cases > where there are more. Indeed, it is well-known that having multiple transactions in progress at the same time is value (though uncommon) --

Re: [Sip-implementors] Query on UAS sending 200 for INVITE before it receives a 200 for an UPDATE it sent

du Subject: Re: [Sip-implementors] Query on UAS sending 200 for INVITE before it receives a 200 for an UPDATE it sent When looking at a race condition, it is always worth looking at RFC 5407 ("Example Call Flows of Race Conditions in SIP", often abbreviated to "Race Conditions in SIP

Re: [Sip-implementors] Query on UAS sending 200 for INVITE before it receives a 200 for an UPDATE it sent

-implementors] Query on UAS sending 200 for INVITE before it receives a 200 for an UPDATE it sent When looking at a race condition, it is always worth looking at RFC 5407 ("Example Call Flows of Race Conditions in SIP", often abbreviated to "Race Conditions in SIP" or even "Haseb

Re: [Sip-implementors] Query on UAS sending 200 for INVITE before it receives a 200 for an UPDATE it sent

When looking at a race condition, it is always worth looking at RFC 5407 ("Example Call Flows of Race Conditions in SIP", often abbreviated to "Race Conditions in SIP" or even "Hasebe" in honor of the author). That is the best collection of carefully analyzed race conditions. I've added to your e

Re: [Sip-implementors] Query on UAS sending 200 for INVITE before it receives a 200 for an UPDATE it sent

On 9/14/16 7:05 AM, Harrison, Jason, Vodafone UK wrote: Hi, I have an issue and I can't identify if the behaviour is wrong: Here is a working call Provider Customer SBCSBC INVITE (SDP offer)--> <--100 Trying <--180 Ringing (SDP answer) PRACK --> <-- 200OK (

Re: [Sip-implementors] Query on UAS sending 200 for INVITE before it receives a 200 for an UPDATE it sent

> In the failed call I am being told by the provider > that their SBC sent a BYE because the 200OK for the > INVITE was received before it managed to send the > 200OK for the UPDATE, I have checked the RFCs and > can't find if the customer SBC is breaking any rules > by sending an 200OK for the INV

[Sip-implementors] Query on UAS sending 200 for INVITE before it receives a 200 for an UPDATE it sent

Hi, I have an issue and I can't identify if the behaviour is wrong: Here is a working call Provider Customer SBCSBC INVITE (SDP offer)--> <--100 Trying <--180 Ringing (SDP answer) PRACK --> <-- 200OK (PRACK) <-- UPDATE 200OK UPDATE --> <--200OK (INVITE) ACK -

Re: [Sip-implementors] [SIP-IMPLEMENTORS] Query related to Call Transfer

Hi Brett, Thank you for the response, On Mon, Apr 18, 2016 at 2:40 PM, Brett Tate wrote: > > I am reading the RFC5589 related to the Call Transfer. > > > > > In Examples it is mentioned as below > > 6.1. Successful Transfer > > Why in the CSeq Method value is REFER ? > > The RFC contains som

Re: [Sip-implementors] [SIP-IMPLEMENTORS] Query related to Call Transfer

> I am reading the RFC5589 related to the Call Transfer. > In Examples it is mentioned as below > 6.1. Successful Transfer > Why in the CSeq Method value is REFER ? The RFC contains some errors. See errata 1892. https://www.rfc-editor.org/errata_search.php?rfc=5589 ___

[Sip-implementors] [SIP-IMPLEMENTORS] Query related to Call Transfer

Hi All, I am reading the RFC5589 related to the Call Transfer. In Examples it is mentioned as below 6.1 . Successful Transfer Transferor Transferee Transfer ||

Re: [Sip-implementors] Query in handling 180 response by proxy

nks, Neel From: sip-implementors-boun...@lists.cs.columbia.edu on behalf of Ramachandran, Agalya (Contractor) Sent: Tuesday, March 15, 2016 10:38:34 AM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] Query in handling 180 response by proxy Hi All, If

Re: [Sip-implementors] Query in handling 180 response by proxy

Thanks, > Paul > >> Thanks, >> Arun >> >> >>> >>>Thanks, >>>Paul >>> >>>> Thanks, >>>> >>>> Neel >>>> >>>> >>>> F

Re: [Sip-implementors] Query in handling 180 response by proxy

Ramachandran, Agalya (Contractor) Sent: Tuesday, March 15, 2016 10:38:34 AM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] Query in handling 180 response by proxy Hi All, If an Invite request is received to a proxy, proxy then forks the Invite message to two destinations. 180

Re: [Sip-implementors] Query in handling 180 response by proxy

, Paul Thanks, Neel From: sip-implementors-boun...@lists.cs.columbia.edu on behalf of Ramachandran, Agalya (Contractor) Sent: Tuesday, March 15, 2016 10:38:34 AM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] Query in handling

Re: [Sip-implementors] Query in handling 180 response by proxy

Ramachandran, Agalya (Contractor) Sent: Tuesday, March 15, 2016 10:38:34 AM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] Query in handling 180 response by proxy Hi All, If an Invite request is received to a proxy, proxy then forks the Invite message to two destinations. 180

Re: [Sip-implementors] Query in handling 180 response by proxy

From: sip-implementors-boun...@lists.cs.columbia.edu on behalf of Ramachandran, Agalya (Contractor) Sent: Tuesday, March 15, 2016 10:38:34 AM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] Query in handling 180 response by proxy Hi All, If an

Re: [Sip-implementors] Query in handling 180 response by proxy

Hi Agalya, Very specific to your scenario for 180 without SDP , There can be 2 scenarios based on which it depends whether to send all forked 180 or not . A side fork not supported :First 180 sent and next 180 with different to-tag is consumed by proxy A side fork supported : Both 180s relayed to

Re: [Sip-implementors] Query in handling 180 response by proxy

"Ramachandran, Agalya (Contractor)" writes: > If an Invite request is received to a proxy, proxy then forks the > Invite message to two destinations. > 180 Ringing Response is received from both the destinations to the proxy. > Proxy is now forwarding both 180 Response to the request originator.

Re: [Sip-implementors] Query in handling 180 response by proxy

asked proxy should forward only the ringing response in > which call leg it has been answered ? > > > > Regards, > Agalya > > *From:* ankur bansal [mailto:abh.an...@gmail.com] > *Sent:* Thursday, March 17, 2016 2:59 PM > *To:* Ramachandran, Agalya (Contractor) > *Cc:*

[Sip-implementors] Query in handling 180 response by proxy

Hi All, If an Invite request is received to a proxy, proxy then forks the Invite message to two destinations. 180 Ringing Response is received from both the destinations to the proxy. Proxy is now forwarding both 180 Response to the request originator. Is this right behavior of proxy or it should

Re: [Sip-implementors] Query in handling 180 response by proxy

response in which call leg it has been answered ? Regards, Agalya From: ankur bansal [mailto:abh.an...@gmail.com] Sent: Thursday, March 17, 2016 2:59 PM To: Ramachandran, Agalya (Contractor) Cc: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Query in handling 180 response by

Re: [Sip-implementors] Query in handling 180 response by proxy

Behalf Of Ramachandran, Agalya > (Contractor) > Sent: Tuesday, March 15, 2016 11:41 AM > To: sip-implementors@lists.cs.columbia.edu > Subject: [Sip-implementors] Query in handling 180 response by proxy > > Hi All, > > If an Invite request is received to a proxy, proxy then

[Sip-implementors] Query in handling 180 response by proxy

Hi All, If an Invite request is received to a proxy, proxy then forks the Invite message to two destinations. 180 Ringing Response is received from both the destinations to the proxy. Proxy is now forwarding both 180 Response to the request originator. Is this right behavior of proxy or it should

Re: [Sip-implementors] Query for refresher value in 200 OK of INVITE

Hi, > UAC (Caller) UAS(Callee) As an fyi, the UAC/UAS labels within the figure are not accurate since requests are sent is both directions. User Agent Client and User Agent Server are defined within RFC 3261 section 6. > 1. Can the refresher value be changed in the SE header > of the

Re: [Sip-implementors] Query for refresher value in 200 OK of INVITE

>> I think a UAS is forbidden to include a Session-Expires header field >> in the UPDATE request and a UAC should reject it. >> In that case, the value of session refresher in 200 OK of INVITE MUST >> be uac. > > I'm not sure why you think that it is forbidden. > > RFC 4024 table 1 shows tha

Re: [Sip-implementors] Query for refresher value in 200 OK of INVITE

On 3/10/16 6:52 AM, Brett Tate wrote: I think a UAS is forbidden to include a Session-Expires header field in the UPDATE request and a UAC should reject it. In that case, the value of session refresher in 200 OK of INVITE MUST be uac. I'm not sure why you think that it is forbidden. RFC 4024 t

Re: [Sip-implementors] Query for refresher value in 200 OK of INVITE

yeah agree with Brett .It should not be forbidden rather should be replied with SE and refresher parameter. I think user A should have sent refresher role as UAS instead of UAC in 200ok of UPDATE to clearly say User A is acting as refresher as how he intended to be refresher in INVITE by putting U

Re: [Sip-implementors] Query for refresher value in 200 OK of INVITE

> I think a UAS is forbidden to include a Session-Expires header field in > the > UPDATE request and a UAC should reject it. > In that case, the value of session refresher in 200 OK of INVITE MUST be > uac. I'm not sure why you think that it is forbidden. RFC 4024 table 1 shows that Session-Expir

Re: [Sip-implementors] Query for refresher value in 200 OK of INVITE

Hi, I think a UAS is forbidden to include a Session-Expires header field in the UPDATE request and a UAC should reject it. In that case, the value of session refresher in 200 OK of INVITE MUST be uac. Regards, Shinji >Hello, > >I have some queries in the below scenario : > UAC

Re: [Sip-implementors] : Query for refresher value in 200 OK of INVITE

> <---UPDATE > > (Session-Expires:3600;refresher=none) The header is malformed. The valid refresher values are indicated within RFC 4028 section 4. > [Query]: What should be the value of session refresher in 200 OK of INVITE? The refresher should be "u

[Sip-implementors] : Query for refresher value in 200 OK of INVITE

Hello, I have some queries in the below scenario : UAC UAS --- INVITE --> (Session-Expires:3600;refresher=uac) <183 Session Progress -PRACK ---

Re: [Sip-implementors] query on presence

Thanks a lot for your reply . Regards,Sreejith From: "a...@ag-projects.com" To: Sreejith Sadaasivan Cc: "sip-implementors@lists.cs.columbia.edu" Sent: Friday, 20 February 2015 9:21 PM Subject: Re: [Sip-implementors] query on presence On 20 Feb 2015

Re: [Sip-implementors] query on presence

On 2/20/15 10:51 AM, a...@ag-projects.com wrote: On 20 Feb 2015, at 09:50, Sreejith Sadaasivan wrote: Hi All, I have a doubt on presence subscription of a buddy. 1) whether it is always mandatory to subscribe to a buddy with "SUBSCRIBE" message to retrieve the presence of a buddy? Yes

Re: [Sip-implementors] query on presence

On 20 Feb 2015, at 09:50, Sreejith Sadaasivan wrote: > Hi All, > I have a doubt on presence subscription of a buddy. > > 1) whether it is always mandatory to subscribe to a buddy with "SUBSCRIBE" > message to retrieve the presence of a buddy? Yes > 2) is there anyway we can directly retriev

[Sip-implementors] query on presence

Hi All, I have a doubt on presence subscription of a buddy. 1) whether it is always mandatory to subscribe to a buddy with "SUBSCRIBE" message to retrieve the presence of a buddy?2) is there anyway we can directly retrieve the presence of a buddy without subscribing ( without sending SUBSCRIBE

[Sip-implementors] Query on M line in SDP

Hi Team, I am getting in ACR (Accounting Charinging Request )that , The SDP-Media-Name has the following string: "m=image 0 udptl t38 ? m=image 0 udptl t38 ?m=audio 11348 RTP/AVP 8 0" The MM only validates nule strings, with 1 or 2 fields,

Re: [Sip-implementors] Query regarding SDP negotiation

...@gmail.com Subject: Re: [Sip-implementors] Query regarding SDP negotiation Hi Brett & Ankur, At first thanks to both of you for your prompt answer. So after considering RFC 3264 ( importantly the section 8.3.2 mentioned in Ankur's latest reply) & RFC 4566, I came to this conclusi

Re: [Sip-implementors] Query regarding SDP negotiation

If g. R Sent from my BlackBerry 10 smartphone on the Rogers network.   Original Message   From: ankur bansal Sent: Wednesday, November 5, ( $#!14 10:54 PM To: Paul Kyzivat Cc: sip-implementors Subject: Re: [Sip-implementors] Query regarding SDP negotiation Saurav We always try to complete call

Re: [Sip-implementors] Query regarding SDP negotiation

Saurav We always try to complete call somehow as providing reliable service to user is utmost important and i have seen solutions voilating standards in actual deployments to provide services to end user. And luckily in our scenario standard is recommending the acceptance of diff payloads to make c

Re: [Sip-implementors] Query regarding SDP negotiation

On 11/5/14 7:05 AM, Brett Tate wrote: But my newer question is even by sending BYE for this flow A is not violating any RFC. Since from the booth RFCs mentioned above the expected behavior mentioned by Ankur is SHOULD way not in MUST. So A behavior may not the be best one but also not a violatio

Re: [Sip-implementors] Query regarding SDP negotiation

> But my newer question is even by sending BYE for this > flow A is not violating any RFC. Since from the booth > RFCs mentioned above the expected behavior mentioned > by Ankur is SHOULD way not in MUST. So A behavior > may not the be best one but also not a violation of RFC. > > Whether my above

Re: [Sip-implementors] Query regarding SDP negotiation

-boun...@lists.cs.columbia.edu [mailto:sip > -implementors-boun...@lists.cs.columbia.edu] On Behalf Of Sourav Dhar > Chaudhuri > Sent: Tuesday, November 04, 2014 2:20 PM > To: ankur bansal > Cc: sip-implementors@lists.cs.columbia.edu > Subject: Re: [Sip-implementors] Query regarding SD

Re: [Sip-implementors] Query regarding SDP negotiation

implementors-boun...@lists.cs.columbia.edu] On Behalf Of Sourav Dhar Chaudhuri Sent: Tuesday, November 04, 2014 2:20 PM To: ankur bansal Cc: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Query regarding SDP negotiation Hi Ankur, Thanks for your clarification. My question still remains

Re: [Sip-implementors] Query regarding SDP negotiation

sage- > From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip- > implementors-boun...@lists.cs.columbia.edu] On Behalf Of Sourav Dhar > Chaudhuri > Sent: Tuesday, November 04, 2014 2:20 PM > To: ankur bansal > Cc: sip-implementors@lists.cs.columbia.edu > Subject: R

Re: [Sip-implementors] Query regarding SDP negotiation

Please refer rfc 3264 section 8.3.2 On Nov 5, 2014 12:50 AM, "Sourav Dhar Chaudhuri" wrote: > Hi Ankur, >Thanks for your clarification. My question still remains. > >In the offer from A does not have the support for payload no 101. So > why you are saying it A SHOULD use it towards B ins

Re: [Sip-implementors] Query regarding SDP negotiation

to:sip- > implementors-boun...@lists.cs.columbia.edu] On Behalf Of Sourav Dhar > Chaudhuri > Sent: Tuesday, November 04, 2014 2:20 PM > To: ankur bansal > Cc: sip-implementors@lists.cs.columbia.edu > Subject: Re: [Sip-implementors] Query regarding SDP negotiation > > Hi Ankur, >

Re: [Sip-implementors] Query regarding SDP negotiation

Hi Ankur, Thanks for your clarification. My question still remains. In the offer from A does not have the support for payload no 101. So why you are saying it A SHOULD use it towards B instead of BYE. where only B has mentioned any payload support on 101. What is the basis of A should do

Re: [Sip-implementors] Query regarding SDP negotiation

Hi Saurav I believe there is no issue due to rtpmap as its required only for dynamic payloads and not for static payloads . Reason of UE A sending BYE could be mismatch in payload no for telephony event . A is sending 99 but B is sending 101 .So A finds this wrong and send BYE But UE A* should no

[Sip-implementors] Query regarding SDP negotiation

Hi, I am observing a behavior SDP negotiation. In the Below Example just After Media Negotiation. A is sending BYE without any media flow . Please refer the below call flow & my query. A --- INVITE with SDP -> B ## SDP details in Of

Re: [Sip-implementors] Query regarding IOI inP-Charging-Vector

Hi, The P-Charging-Vector is supported by MSC-S only if SIP call is routed to or from a trusted domain. Whether a network domain is trusted or not can be configured in the MSC Server on a route basis.  TRUSTPL parameter determines whether a Trust Policy is supported on the SIP/SIP-I route. When

[Sip-implementors] Query regarding IOI inP-Charging-Vector

Hi, Is it possible to configure custom IOI and/or FNI filed in P-Charging-Vector in SIP message header per traffic route? Thanks & Regards, Sourav Dhar Chaudhuri ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs

Re: [Sip-implementors] Query on forked responses

ists.cs.columbia.edu > Subject: [Sip-implementors] Query on forked responses > > Hi > > Is following a valid scenario? > > When an INVITE client transaction is in the Calling state, on receipt > of Success (200 OK) responses differing only on the tag in the To > header, sends

[Sip-implementors] Query on forked responses

Hi Is following a valid scenario? When an INVITE client transaction is in the Calling state, on receipt of Success (200 OK) responses differing only on the tag in the To header, sends an ACK request with a To header identical to the received one for each received Success (200 OK) responses. Th

Re: [Sip-implementors] Query on Contact header parameter

gt; [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Sreejith > Sadaasivan > Sent: Friday, March 21, 2014 9:57 PM > To: sip-implementors@lists.cs.columbia.edu; Paul Kyzivat > Subject: Re: [Sip-implementors] Query on Contact header parameter > > Hello, > > Plea

Re: [Sip-implementors] Query on Contact header parameter

@lists.cs.columbia.edu; Paul Kyzivat Subject: Re: [Sip-implementors] Query on Contact header parameter Hello, Please remove me from this mailing list. Regards, SREE On Fri, 21/3/14, Paul Kyzivat wrote: Subject: Re: [Sip-implementors] Query on Contact header

Re: [Sip-implementors] Query on Contact header parameter

Hello, Please remove me from this mailing list. Regards, SREE On Fri, 21/3/14, Paul Kyzivat wrote: Subject: Re: [Sip-implementors] Query on Contact header parameter To: sip-implementors@lists.cs.columbia.edu Date: Friday, 21 March, 2014, 8:43 AM

Re: [Sip-implementors] Query on Contact header parameter

You have now received answers to the question you asked. But not to the one you should have asked: how can you do this in a way that doesn't violate standards? The procedure for managing new header field parameters was updated by RFC 3968. There is an IANA registry, and you need an RFC to defi

Re: [Sip-implementors] Query on Contact header parameter

oken = 1*(alphanum / "-" / "." / "!" / "%" / "*" > > / "_" / "+" / "`" / "'" / "~" ) > > > >> -----Original Message- > >> From: sip-imp

Re: [Sip-implementors] Query on Contact header parameter

; sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Query on Contact header parameter Hi Olle, AFAIK per title and the following snippet, he asked for Contact header parameter. I'm not positive what you are asking about (sip-uri header parameters, generic header confor

Re: [Sip-implementors] Query on Contact header parameter

rvalue > -Original Message- > From: Olle E. Johansson [mailto:o...@edvina.net] > Sent: Friday, March 21, 2014 8:09 AM > To: Brett Tate > Cc: Olle E Johansson; J C Sunil Kumar Reddy; sip- > implement...@lists.cs.columbia.edu > Subject: Re: [Sip-implementors] Query on C

Re: [Sip-implementors] Query on Contact header parameter

t;*" > / "_" / "+" / "`" / "'" / "~" ) > >> -Original Message- >> From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip- >> implementors-boun...@lists.cs.columbia.edu] On Behalf Of J C Suni

Re: [Sip-implementors] Query on Contact header parameter

/ "_" / "+" / "`" / "'" / "~" ) > > > -Original Message- > > From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip- > > implementors-boun...@lists.cs.columbia.edu] On Behalf Of J C Sunil > &g

Re: [Sip-implementors] Query on Contact header parameter

; implementors-boun...@lists.cs.columbia.edu] On Behalf Of J C Sunil > Kumar Reddy > Sent: Friday, March 21, 2014 6:33 AM > To: sip-implementors@lists.cs.columbia.edu > Subject: [Sip-implementors] Query on Contact header parameter > > Hi All, > > I need to send a propriet

Re: [Sip-implementors] Query on Contact header parameter

On 21 Mar 2014, at 11:33, J C Sunil Kumar Reddy wrote: > Hi All, > > I need to send a proprietary parameter in contact header in an INVITE > message to other end. > Something like this: > > Contact: "Sunil" ;category:strvalue > > Here "category:strvalue" is my proprietary parameter. Where "ca

[Sip-implementors] Query on Contact header parameter

Hi All, I need to send a proprietary parameter in contact header in an INVITE message to other end. Something like this: Contact: "Sunil" ;category:strvalue Here "category:strvalue" is my proprietary parameter. Where "category" is a param name and "strvalue" is the value. What does the SIP stan

[Sip-implementors] Query about percentage Impact of race condition

Hi, Does any one did any R&D about percentage impact of race condition or how many such calls may occur per day etc... Thanks, Kiran. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/

Re: [Sip-implementors] Query on Contact in INVITE

> Contact: context=+34@10.31.255.134:5070;endpoint=192.168.126.12;transport=udp> > > Should the ReINVITE be sent to 10.31.255.134:5070 in this case? Yes; I'll assume that there isn't a policy reason (security, nat traversal, endpoint parameter meaning, et cetera) to do otherwise. -- This emai

Re: [Sip-implementors] Query on Contact in INVITE

bruary 10, 2014 4:17 PM To: Tarun2 Gupta; sip-implementors@lists.cs.columbia.edu Subject: RE: [Sip-implementors] Query on Contact in INVITE > Is the following a valid example of a Contact in INVITE: No; the missing brackets cause the parameters to decode as header parameters instead of being pa

Re: [Sip-implementors] Query on Contact in INVITE

> Is the following a valid example of a Contact in INVITE: No; the missing brackets cause the parameters to decode as header parameters instead of being part of the sip-uri. This causes the '@' to be an invalid header parameter character. Similarly, "917163166" wouldn't decode correctly as a "ho

[Sip-implementors] Query on Contact in INVITE

Hi Is the following a valid example of a Contact in INVITE: Contact: sip:917163166;phone-context=+34@10.31.255.134:5070;endpoint=192.168.126.12;transport=udp If yes, what IP:Port should be used by the UAS to send a ReINVITE? Can you give me any normative references in support of the above ABNF

Re: [Sip-implementors] Query on Provisional response

> It is valid to send subsequent provisional response > without SDP when previous provisional response has > SDP in it. Yes. > Does any RFC allow/block above flow. Nothing blocks it. Among other potential references, RFC 3262 discusses periodic reliable responses. This can be situation whe

  1   2   3   4   5   6   7   >