[Sip-implementors] retrieve IMEI of device

[Ranjit Avasarala]

Hi experts

I know device's send their IMEI in SIP INVITE for 911 calls and in SIP
REGISTER requests.  But they usually do not send IMEI in SIP INVITE for
regular calls.

So in such cases is there a way the call handling server can get the IMEI
of the device that is originating the call?

Thanks
Ranjit
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Call route advance standard

[Ranjit Avasarala]

Hi Amanpreet

You can configure your B2BUA to use the same call-id on the second trunk
too.

On Fri, Mar 29, 2024 at 1:08 AM Amanpreet Singh 
wrote:

> Thanks Dale for your inputs.
> My UAC is B2BUA and thus sending a new call-id in INVITE for the route
> advance to the next trunk.
>
> Ranjit,
> Peer is expecting the same call-id on the second trunk after route advance,
> was wondering if we have something around this to find a common ground to
> address this.
>
>
>
> Regards,
> Aman
>
>
> On Thu, Mar 28, 2024 at 11:56 PM Dale R. Worley 
> wrote:
>
> > Amanpreet Singh  writes:
> > > I'm looking to see if there is any RFC defining the standard around
> route
> > > advance/ re-routing of calls to the next available route based on the
> SIP
> > > failure response.
> > >
> > > Looked into SIP Peering RFC6271 and RFC5486, however it doesn't cover
> the
> > > route advance requirements.
> >
> > In regard to the SIP *specification*, a critical question is the nature
> > of the device that is forwarding the call onward and doing route
> > advance.  If it is sending outward INVITEs with the same Call-ID as the
> > INVITE it receives, it is a "proxy" doing "sequential forking", and the
> > requirements are in RFC 3261.  What changes the proxy is allowed to make
> > on the call as it passes through are relatively limited.
> >
> > OTOH, if the outward INVITE has a different Call-ID, then the device is
> > a "back-to-back user agent" (B2BUA), and from the SIP point of view, it
> > is the UAS of the arriving INVITE and the UAC of the outgoing INVITE.
> > The SIP specifications place no limits on what a B2BUA may do, including
> > sending out what are effectively different forks of a call with
> > different Call-IDs.
> >
> > A lot of telephony systems use B2BUAs rather than the SIP proxies that
> > were envisioned in the original SIP architecture.
> >
> > > To be specific, we have SIP trunks with a provider, when a call fails
> on
> > > the first trunk with SIP 50X UAC is doing route advance to the next
> trunk
> > > with that provider as per priority. UAC is generating a new call-id in
> > the
> > > INVITE for call to the second trunk; however the peer expects the
> INVITE
> > > with the same call-id.
> >
> > There are two factors involved.  One is whether the device claims to be
> > a proxy, in which case it is required to use the same Call-ID on
> > different forks of a call that it handles.  The other is what the
> > trunking provider *requires*, which isn't necessarily limited by the SIP
> > specifications.  As a matter of good system architecture, I would expect
> > that alternative forks of one call would have the same Call-ID, so that
> > downstream devices can tell that they *are* alternative forks of one
> > call.
> >
> > Dale
> >
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Call route advance standard

[Ranjit Avasarala]

thats the expected behavior.  why do u need RFC to define that behavior.

Regards
Ranjit

On Thu, Mar 28, 2024 at 9:04 AM Amanpreet Singh 
wrote:

> Hello All,
>
> I'm looking to see if there is any RFC defining the standard around route
> advance/ re-routing of calls to the next available route based on the SIP
> failure response.
>
> Looked into SIP Peering RFC6271 and RFC5486, however it doesn't cover the
> route advance requirements.
>
> To be specific, we have SIP trunks with a provider, when a call fails on
> the first trunk with SIP 50X UAC is doing route advance to the next trunk
> with that provider as per priority. UAC is generating a new call-id in the
> INVITE for call to the second trunk; however the peer expects the INVITE
> with the same call-id.
>
> Seeking your help for RFC to refer to conclude this, thanks in advance.
>
>
> Thanks,
> Amanpreet Singh.
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] What is the rule for retransmitting the SIP packet

[Ranjit Avasarala]

TCP takes care of re-transmissions.

On Mon, Apr 10, 2023 at 11:25 AM Arun T  wrote:

> Thanks RFC talks about the non-reliable transport (UDP) what about reliable
> transport (TCP). Don’t UE/NW retransmit?
>
> On Mon, 10 Apr 2023 at 7:12 PM, Roman Shpount  wrote:
>
> > Please take a look at hhttps://www.rfc-editor.org/rfc/rfc3261#section-17
> > _
> >
> > Roman Shpount
> >
> >
> > On Mon, Apr 10, 2023 at 9:20 AM Arun T  wrote:
> >
> >> Hi All,
> >>
> >> Can any one share the spec./RFC which has information that SIP messages
> >> can
> >> be re-transmitted if no response is received?
> >>
> >> What is the interval for retransmitting ? And how many retransmissions
> are
> >> permitted or allowed ? Does it depend on any timer ?
> >>
> >> --
> >>
> >> With Regards
> >>
> >> Arun A. Tagare
> >> +91 9449 029729
> >> ___
> >> Sip-implementors mailing list
> >> Sip-implementors@lists.cs.columbia.edu
> >> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> >>
> > --
>
> With Regards
>
> Arun A. Tagare
> +91 9449 029729
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] [SIPForum-discussion] RTP packet loss tolerance/ timers

[Ranjit Avasarala]

Hi Amanpreet

RTP by itself does not have any timers, so it's the responsibility of the
application to make sure all packets are sent and received or re-transmit
if needed.  Also RTCP provides various reports like SR, RR, XR that give
useful information about RTP packet quality.  Refer to RFC 3550 for all
report types.
E.g SR is sent periodically by active senders while RR is sent for passive
participants

Regards
Ranjit

On Sun, Sep 25, 2022 at 8:10 AM Amanpreet Singh 
wrote:

> Dale,
> I'm looking for the best practices to have minimum packet loss/ delays in
> case of primary network link failure. As the network secondary link takes
> about 3 seconds to come up.
>
> What best we can do on the application side to have the minimum RTP packet
> loss? Do we have timeout, retransmission timers for RTP, or any mechanism
> to adjust to minimize the loss. if not adjustable, default values based on
> which we can try changing network layer failover.
>
>
> Thanks,
> Amanpreet Singh.
>
>
> On Sun, Sep 25, 2022 at 7:38 AM Dale R. Worley  wrote:
>
> > Amanpreet Singh  writes:
> > > We are working with our network team for audio/video traffic routing,
> > some
> > > of the liks are not redundant and failover takes around 3 seconds to
> > route
> > > the packets on the new link.
> > >
> > > I'm trying to understand if we have some standard timers defined (have
> > gone
> > > through the RFC 3550 and 4585) for RTP but couldn't find.
> > > My understanding is, transport for RTP is UDP, which does not offer
> > > reliability and left upto the application to determine the packet loss
> > and
> > > inform the user.
> >
> > I haven't heard of any.  But could you provide some detail what the
> > usage would be of a timer that you're looking for?
> >
> > Dale
> >
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] How to differentiate Hold RTP and voice RTP

[Ranjit Avasarala]

Hi Arun

you won't get RTP from NW and end point at the same time.  consider this
scenario:  User Alice calls User Bob.  Now Bob is busy with other call.  So
here User Alice will hear a hold tone i.e busy signal and would get 486
Busy here.  Here SSRC would be server . So now Alice will not get any RTP
packets from User Bob

Then User Alice may remain on hold or disconnect or can request call back.
So when user Alice get call back and gets connected with User Bob, then
User Alice will see RTP packets from User B - these are end to end.  Here
SSRC would be User Bob.

So looking at SSRC / Source in RTP, you can differentiate.  Also hold
packets will have music which can tell u that they are for hold.



On Thu, Sep 22, 2022 at 9:56 AM Arun Tagare  wrote:

> Thanks Ranjit,
>
> Yes for the signalling part i am aware, but as shared earlier how the RTP
> from N/w and other UE in same session be differentiate?
>
> So SSRC will be different right?
>
> On Thu, 22 Sep 2022 at 8:05 PM, Ranjit Avasarala 
> wrote:
>
>> Hi Arun
>>
>> Both are technically voice packets and use RTP protocol.  So that way
>> both are similar.  Also the voice traffic is end to end whereas hold music
>> is from the server.  Like announcement - may be from Application Server.
>> So looking at the SSRC or Source in RTP Packets, you should be able to say
>> which entity is sending those packets.
>>
>> Another way to check is the SDP.  for hold music,  the media attribute
>> will be sendonly.  where as for regular voice traffic it will sendrecv
>>
>> Regards
>> Ranjit
>>
>> On Thu, Sep 22, 2022 at 4:19 AM Amanpreet Singh <
>> amanpreeet.si...@gmail.com> wrote:
>>
>>> Arun, for what purpose would you like to inspect and differentiate the
>>> hold
>>> and audio RTP packets?
>>> and based on the signaling messages, can't that be achieved.
>>>
>>> Thanks,
>>> Amanpreet Singh.
>>>
>>>
>>> On Thu, Sep 22, 2022 at 12:30 PM Arun Tagare 
>>> wrote:
>>>
>>> > Thanks Ranjit & Amanpreet, for your response
>>> >
>>> > But my question is
>>> >
>>> > MT <= Call Established ===> MO
>>> > MT <===> Voice RTP Packets flow <=> MO
>>> > MT <==Hold ===> MO
>>> > MT < HOLD Tone RTP packets == NW
>>> >
>>> > Both Voice RTP packets and Hold RTP packets come to the same port
>>> right ?
>>> > How to differentiate these RTP packets
>>> >
>>> > On Thu, Sep 22, 2022 at 11:06 AM Amanpreet Singh <
>>> > amanpreeet.si...@gmail.com> wrote:
>>> >
>>> >> Probably you can think of looking into the signaling messages(SDP in
>>> case
>>> >> of SIP) to differentiate when the call is on hold and when not i.e.
>>> normal
>>> >> audio RTP.
>>> >>
>>> >> BTW what is the use case to differentiate call hold vs audio RTP?
>>> >>
>>> >>
>>> >> Regards,
>>> >> Amanpreet Singh.
>>> >>
>>> >>
>>> >> On Wed, Sep 21, 2022 at 9:51 PM Arun Tagare 
>>> >> wrote:
>>> >>
>>> >>> Hi All,
>>> >>>
>>> >>> I have a doubt on the Hold call tone or music on hold tone RTP v/s
>>> actual
>>> >>> voice RTP before hold
>>> >>>
>>> >>> Can these RTP packets be able to differentiate?
>>> >>> If yes how?
>>> >>> if not why?
>>> >>>
>>> >>> Thanks a lot to everyone in advance
>>> >>>
>>> >>> --
>>> >>>
>>> >>> With Regards
>>> >>>
>>> >>> Arun A. Tagare
>>> >>> +91 9449 029729
>>> >>> ___
>>> >>> Sip-implementors mailing list
>>> >>> Sip-implementors@lists.cs.columbia.edu
>>> >>> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>>> >>>
>>> >>
>>> >
>>> > --
>>> >
>>> > With Regards
>>> >
>>> > Arun A. Tagare
>>> > +91 9449 029729
>>> >
>>> ___
>>> Sip-implementors mailing list
>>> Sip-implementors@lists.cs.columbia.edu
>>> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>>>
>> --
>
> With Regards
>
> Arun A. Tagare
> +91 9449 029729
>
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] How to differentiate Hold RTP and voice RTP

[Ranjit Avasarala]

Hi Arun

Both are technically voice packets and use RTP protocol.  So that way both
are similar.  Also the voice traffic is end to end whereas hold music is
from the server.  Like announcement - may be from Application Server.  So
looking at the SSRC or Source in RTP Packets, you should be able to say
which entity is sending those packets.

Another way to check is the SDP.  for hold music,  the media attribute will
be sendonly.  where as for regular voice traffic it will sendrecv

Regards
Ranjit

On Thu, Sep 22, 2022 at 4:19 AM Amanpreet Singh 
wrote:

> Arun, for what purpose would you like to inspect and differentiate the hold
> and audio RTP packets?
> and based on the signaling messages, can't that be achieved.
>
> Thanks,
> Amanpreet Singh.
>
>
> On Thu, Sep 22, 2022 at 12:30 PM Arun Tagare 
> wrote:
>
> > Thanks Ranjit & Amanpreet, for your response
> >
> > But my question is
> >
> > MT <= Call Established ===> MO
> > MT <===> Voice RTP Packets flow <=> MO
> > MT <==Hold ===> MO
> > MT < HOLD Tone RTP packets == NW
> >
> > Both Voice RTP packets and Hold RTP packets come to the same port right ?
> > How to differentiate these RTP packets
> >
> > On Thu, Sep 22, 2022 at 11:06 AM Amanpreet Singh <
> > amanpreeet.si...@gmail.com> wrote:
> >
> >> Probably you can think of looking into the signaling messages(SDP in
> case
> >> of SIP) to differentiate when the call is on hold and when not i.e.
> normal
> >> audio RTP.
> >>
> >> BTW what is the use case to differentiate call hold vs audio RTP?
> >>
> >>
> >> Regards,
> >> Amanpreet Singh.
> >>
> >>
> >> On Wed, Sep 21, 2022 at 9:51 PM Arun Tagare 
> >> wrote:
> >>
> >>> Hi All,
> >>>
> >>> I have a doubt on the Hold call tone or music on hold tone RTP v/s
> actual
> >>> voice RTP before hold
> >>>
> >>> Can these RTP packets be able to differentiate?
> >>> If yes how?
> >>> if not why?
> >>>
> >>> Thanks a lot to everyone in advance
> >>>
> >>> --
> >>>
> >>> With Regards
> >>>
> >>> Arun A. Tagare
> >>> +91 9449 029729
> >>> ___
> >>> Sip-implementors mailing list
> >>> Sip-implementors@lists.cs.columbia.edu
> >>> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> >>>
> >>
> >
> > --
> >
> > With Regards
> >
> > Arun A. Tagare
> > +91 9449 029729
> >
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] SIP over QUIC

[Ranjit Avasarala]

Could you move this discussion to sipcore?

On Thu, Jun 30, 2022 at 2:50 AM Filippos Vasilakis 
wrote:

> Hello everyone,
>
> Has anyone implemented SIP over QUIC, or started looking at that ? We will
> start looking at that soon, so I was wondering about other people's
> experiences on that topic, or any pointers/hints on non-trivial things that
> we should take extra care of.
>
> /Filippos
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] fmtp is missing in the retransmitted 200ok

[Ranjit Avasarala]

Hi Anusha

Can you share the message details of 200 OK - the first one with fmtp line
and 2nd one without fmtp line? Also did you capture TCP dump between callee
and freeswitch to check why freeswitch is not receiving ACK?

Regards
Ranjit



On Wed, Apr 20, 2022 at 8:14 AM Anusha Muralidhara <
anushamuralidh...@gmail.com> wrote:

> Hello,
>
> I have a scenario where in ACK from the callee is not being received by the
> Freeswitch for unknown reasons. Hence it is retransmitting 200OK. But in
> the second 200ok message fmtp is missing.
> Can someone please explain why fmtp is not sent in the retransmitted 200 ok
> message ?
>
>
>
>
> Thanks & Regards,
> Anusha Muralidhar
> *India**  Ph:* +91 8088223397
> *Krakow Ph:* +48 579257609
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] SIP REGISTER MESSAGE flow

[Ranjit Avasarala]

Hi Arun

I am not sure how you can get more than 1 P-CSCF address(s) as the P-CSCF
address is discovered by UE i.e returned by GGSN.  So even if we assume a
scenario where the GGSN returns 5 P-CSCF address, then yes u can send
REGISTER to all of them ( but this is not a practical scenario)

Then as per the protocol, all 5 P-CSCFs will respond with 401 and the UE
needs to keep track of all 5 401s and send REGISTER with authentication to
all of them. Then if we assume all of them accept then UE is simultaneously
registered with 5 P-CSCFs

so though theoretically this may seem possible, but should not and will not
occur in a practical scenario

To understand more about P-CSCF discovery refer to 3GPP TS 34.229

Regards
Ranjit

On Sat, Nov 20, 2021 at 1:00 AM Arun Tagare  wrote:

> Hi Team,
>
> Need some info, can UE be allowed (as per rule) to send SIP REGISTER
> requests to all the received P-CSCF addresses from NW (during attach) ?
>
> For Ex.
> If UE received 5 P-CSCF address during attach
>
> Is it allowed to send REG to address at the same time
> UE REG to P-CSCF-1--->
> UE REG to P-CSCF-2--->
> UE REG to P-CSCF-3--->
> UE REG to P-CSCF-4--->
> UE REG to P-CSCF-5--->
>
> <--- 401 from P-CSCF-2
> <--- 401 from P-CSCF-3
> <--- 401 from P-CSCF-5
>
> UE AUTH-REG to P-CSCF-2--->
> UE AUTH-REG to P-CSCF-3--->
> UE AUTH-REG to P-CSCF-5--->
>
> <-- 200 OK from P-CSCF-5
>
> So, UE finally connected to P-CSCF-5
> I know this may increase signalling load on NW, but want to understand is
> this flow allowed as per rules ? Or there are any restrictions please help
> on understanding
>
>
>
> --
>
> With Regards
>
> Arun A. Tagare
> +91 9449 029729
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Troubleshooting an ACK

[Ranjit Avasarala]

May be - I think ACK should have Contact header.  Try adding that and check

On Wed, Aug 25, 2021 at 6:37 PM onewhoknows  wrote:

> I have a UAC sending an ACK for a 200OK (re-INVITE) to a proxy that never
> gets to the UAS, this is what the ACK looks like:
>
> ACK sip:1000@10.69.69.70:5061 SIP/2.0
> Via: SIP/2.0/UDP 10.10.10.11:5068;branch=z08346hjn
> From: ;tag=dfhgq23
> To: "1000" ;tag=8068c88736ec
> Call-ID: 0917235h
> CSeq: 2 ACK
> Max-Forwards: 70
> User-Agent: Rev
> Content-Length: 0
>
> 10.69.69.70 in the R-URI is the UAS
> 10.69.69.69 in the TO header is the proxy
> 10.10.10.11 in the VIA/FROM is the UAC
>
> The ACK goes to the proxy and goes no further, so the 200 OK from the UAS
> keeps re-transmitting until the call drops.
>
> I'm trying to determine if the formatting for the ACK is incorrect or not.
> The original re-INVITE does have route headers, the ACK above as you see,
> does not.
>
> I appreciate any insight you can provide.  If there's additional
> information I can provide, please let me know.
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] [sipcore] RFC 4028 UAS behavior requirement of Require header

[Ranjit Avasarala]

Hi Holi

The RFC says UAS should add a Require: timer in response when UAC is the
refresher to indicate to UAC that it is the refresher. But I think this is
redundant as UAC anyway knows it is the refresher and does not need a
reminder from UAS.

On Fri, May 28, 2021 at 3:18 PM Hoil Choi  wrote:

> Hi Ranjit, thanks for taking a look.
>
> However, I'm more interested in case where UAS is responding to UAC's
> request with refresher as itself (uac).  Consider this case -
>
> UAC  INVITE (Session-Expires: 1800;refresher=uac, Supported: timer)
> > UAS
> UAC < 200 OK (Session-Expires: 1800;refresher=uac)
> - UAS
>
> In this case, the statement in question seems to convey that UAS should
> also add "Require: timer" in its 200 response.  Why would this be, when
> it's clear that UAC declared itself as the refresher and that timer is
> supported?
>
> For reference, RFC 4028 Section 9 UAS Behavior (or page 16)
> If the refresher parameter in the Session-Expires header field in the 2xx
> response has a value of 'uac', the UAS MUST place a Require header field
> into the response with the value 'timer'.
>
> Thanks,
> Hoil
>
> --
> *From:* Ranjit Avasarala 
> *Sent:* Friday, May 28, 2021 12:38 PM
> *To:* Hoil Choi ;
> Sip-implementors@lists.cs.columbia.edu <
> Sip-implementors@lists.cs.columbia.edu>
> *Cc:* sipc...@ietf.org 
> *Subject:* Re: [sipcore] RFC 4028 UAS behavior requirement of Require
> header
>
> Hi Holi
> the presence of the "Require" header with value "timer" from UAS indicates
> to UAC that it (UAC) is performing the refreshing operation. but if the UAS
> is the refresher, then if Require header with value "timer" is present in
> response from UAS, then UAC should send BYE if it does not receive a
> session refresh request from UAS.
>
> Regards
> Ranjit
>
>
>
> On Fri, May 28, 2021 at 10:02 AM Hoil Choi  wrote:
>
> Hello,
>
> I hope this mail finds appropriate person or team for an answer to my
> question on RFC 4028.
> I am a SIP enthusiast and always learning a lot about it, but by no means
> am I an expert; so please excuse my ignorance.
>
> I came across an interesting statement In Section 9 UAS Behavior (or page
> 16).
>
>
> If the refresher parameter in the Session-Expires header field in the
>2xx response has a value of 'uac', the UAS MUST place a Require
>header field into the response with the value 'timer'.
>
>
> Statement seems to convey that UAS must place a Require header with value
> 'timer' when UAC requests itself to be the refresher.
>
> However, this statement should only be true, if UAC did not put
> Session-Expire with value of 'uac'.
>
> If UAC, in INVITE request, put Session-Expire with value of 'uac'
> (itself), UAS should not bother putting Require header field in the
> response.  Or to be more accurate, UAC should include 'timer' in Supported
> header, so that UAS doesn't have to bother putting Require header field.
>
> What is the reason behind the requirement of Require header, from UAS in
> this case?
>
> Thanks!
> Hoil Choi
> 253-273-5442
>
> ___
> sipcore mailing list
> sipc...@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsipcore&data=04%7C01%7C%7C4f68f91aa77847f0fb6508d922102eb4%7C84df9e7fe9f640afb435%7C1%7C0%7C637578275155641932%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3McfrKwjz9RwC%2FBRLtdyopgzmNmUqsAKdAXyyRvChuc%3D&reserved=0>
>
>
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] [sipcore] RFC 4028 UAS behavior requirement of Require header

[Ranjit Avasarala]

Hi Holi
the presence of the "Require" header with value "timer" from UAS indicates
to UAC that it (UAC) is performing the refreshing operation. but if the UAS
is the refresher, then if Require header with value "timer" is present in
response from UAS, then UAC should send BYE if it does not receive a
session refresh request from UAS.

Regards
Ranjit



On Fri, May 28, 2021 at 10:02 AM Hoil Choi  wrote:

> Hello,
>
> I hope this mail finds appropriate person or team for an answer to my
> question on RFC 4028.
> I am a SIP enthusiast and always learning a lot about it, but by no means
> am I an expert; so please excuse my ignorance.
>
> I came across an interesting statement In Section 9 UAS Behavior (or page
> 16).
>
>
> If the refresher parameter in the Session-Expires header field in the
>2xx response has a value of 'uac', the UAS MUST place a Require
>header field into the response with the value 'timer'.
>
>
> Statement seems to convey that UAS must place a Require header with value
> 'timer' when UAC requests itself to be the refresher.
>
> However, this statement should only be true, if UAC did not put
> Session-Expire with value of 'uac'.
>
> If UAC, in INVITE request, put Session-Expire with value of 'uac'
> (itself), UAS should not bother putting Require header field in the
> response.  Or to be more accurate, UAC should include 'timer' in Supported
> header, so that UAS doesn't have to bother putting Require header field.
>
> What is the reason behind the requirement of Require header, from UAS in
> this case?
>
> Thanks!
> Hoil Choi
> 253-273-5442
>
> ___
> sipcore mailing list
> sipc...@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] reuse of payload type

[Ranjit Avasarala]

no it won't, as issue with codecs mismatch and not full/partial offer.
Either of them have to change their codec / PT mapping

Just curious,  does BYE have the reason for call termination?

Regards
Ranjit

On Thu, Feb 4, 2021 at 11:13 PM Arun Tagare  wrote:

> Hi All,
>
> Will it solve if you send FULL offer when UE receive re-Invite w/o SDP
>
> pCSCF - VoLTE-phone
>
> INVITE ->
>
> With SDP offer
>
>  <- 180 Ringing
>
>  <- 200OK with SDP answer
>
> ACK ->
>
> re-INVITE ->
>
> without SDP
>
>  <- 200OK with SDP Offer  <<<<<< Here instead of sending
> negotiated offer try sending full offer
>
> ACK ->
>
> With SDP answer
>
>
>
>
>
> On Mon, Jan 25, 2021 at 7:12 PM Sundbaum Per-Johan (Telenor Sverige AB) <
> per-johan.sundb...@telenor.se> wrote:
>
> > Hi again !
> >
> > I just realized that I didn't answer your question
> >
> > "It looks like there is an attempt to match on PT 108 with AMR/8000. But
> > the codec parameters don't match. Is the expectation that they will be
> > matched by PT and then will attempt to interwork the differing codec
> > parameters?"
> >
> > I'm not sure, but I will  dig some more on the issue !
> >
> > BR/pj
> >
> >
> > Sensitivity: Internal
> >
> > -Original Message-
> > From: Paul Kyzivat 
> > Sent: den 22 januari 2021 23:44
> > To: Sundbaum Per-Johan (Telenor Sverige AB) <
> per-johan.sundb...@telenor.se>;
> > Ranjit Avasarala ;
> > sip-implementors@lists.cs.columbia.edu
> > Subject: Re: [Sip-implementors] reuse of payload type
> >
> > On 1/22/21 12:34 PM, Sundbaum Per-Johan (Telenor Sverige AB) wrote:
> > > Hi !
> > > My tool is exporting the trace as requested, but it seems the resulting
> > .pcap is not decoded so that one is not to any use.
> > > I have attached a HTML-version that I hope is at least a little better
> > than my text.
> >
> > That was fine.
> >
> > Now to analyze this trace...
> >
> > Note that IIUC the matching between offer and answer is done by codec
> name
> > (from rtpmap) and codec parameters (from fmtp. IIUC the individual
> > parameters in the fmtp need to be matched. The order that they are
> written
> > is irrelevant.)
> >
> > (Not by payload type, which can differ on the two ends, though people
> like
> > it better when it doesn't. But in this case it turns out that the PTs do
> > all match between a given offer and answer.)
> >
> > In the first O/A, there is a match between PT 108 on both ends (AMR/8000,
> >
> max-red=0;mode-change-capability=2;mode-change-neighbor=1;mode-change-period=2;mode-set=7).
> >
> > I imagine PT 116 in the answer is intended to match 116 in the offer.
> > But it technically doesn't because they don't have matching fmpt values.
> > I'm guessing it was treated as a match.
> >
> > In the 2nd O/A, treating it independently of the first one, there are
> > matches on 100, 102, 104, 105, 109.
> >
> > Then question you are asking is about the compatibility of Answer#2 and
> > Offer#1. The only match I find is for telephone-event between PT 116 in
> the
> > first answer and PT 100 in the second offer. I think that is what you
> were
> > concerned about. IMO *that* is conforming, since the phone uses
> > 116 in both its first answer and its subsequent offer.
> >
> > It looks like there is an attempt to match on PT 108 with AMR/8000. But
> > the codec parameters don't match. Is the expectation that they will be
> > matched by PT and then will attempt to interwork the differing codec
> > parameters? I don't think that is how it is supposed to work. But this
> > isn't really my area - I know the signaling but not the codec
> manipulation.
> >
> > I find the following violations where a UA uses a PT for different
> > codec/parameters between the first and 2nd Invites:
> >
> > pCSCF: 100, 102, 108
> > phone: 108
> >
> > Thanks,
> > Paul
> >
> >
> >
> > > [cid:image001.png@01D6F0ED.27F177E0]
> > >
> > > BR/pj
> > >
> > > From: Ranjit Avasarala 
> > > Sent: den 22 januari 2021 18:02
> > > To: Sundbaum Per-Johan (Telenor Sverige AB)
> > > 
> > > Subject: Re: [Sip-implementors] reuse of payload type
> > >
> > > Hi Sundhaum
> > >
> > > eithe

Re: [Sip-implementors] reuse of payload type

[Ranjit Avasarala]

Hi Sundbaum
There is a codec mismatch between A and B - either of them have to change
or a transcoder needs to be used

Regards
Ranjit

On Fri, Jan 22, 2021 at 11:34 AM Sundbaum Per-Johan (Telenor Sverige AB) <
per-johan.sundb...@telenor.se> wrote:

> Hi !
>
> My tool is exporting the trace as requested, but it seems the resulting
> .pcap is not decoded so that one is not to any use.
>
> I have attached a HTML-version that I hope is at least a little better
> than my text.
>
>
>
>
>
> BR/pj
>
>
>
> *From:* Ranjit Avasarala 
> *Sent:* den 22 januari 2021 18:02
> *To:* Sundbaum Per-Johan (Telenor Sverige AB) <
> per-johan.sundb...@telenor.se>
> *Subject:* Re: [Sip-implementors] reuse of payload type
>
>
>
> Hi Sundhaum
>
>
>
> either A or B should change in order to make a successful call or make use
> of codec conversion.  instead of pasting the call flows, it will be better
> if u could attach the pcap file.
>
>
>
> On Fri, Jan 22, 2021 at 10:02 AM Sundbaum Per-Johan (Telenor Sverige AB) <
> per-johan.sundb...@telenor.se> wrote:
>
> Much appreciated, thanks !
>
> I have added some more info.
>
>
>
> pCSCF - VoLTE-phone
>
> INVITE ->
>
> With SDP offer
>
>  <- 180 Ringing
>
>  <- 200OK with SDP answer
>
> ACK ->
>
> re-INVITE ->
>
> without SDP
>
>  <- 200OK with SDP Offer
>
> ACK ->
>
> With SDP answer
>
>
>
>
>
> SDP in initial INVITE
> SDP PDU
>  v=0
>  o=- 805658488335263 1704590316 IN IP6 2A02:1400:10:1C::4
>  s=-
>  c=IN IP6 2a02:1400:10:1::4
>  t=0 0
>  m=audio 5394 RTP/AVP 108 102 8 100 96 0 116 111
>  b=AS:141
>  a=rtpmap:108 AMR/8000
>  a=fmtp:108 mode-set=7; mode-change-period=2;
> mode-change-capability=2; mode-change-neighbor=1; max-red=0
>  a=rtpmap:102 AMR/8000
>  a=fmtp:102 mode-set=7; max-red=0
>  a=rtpmap:8 PCMA/8000
>  a=rtpmap:100 AMR/8000
>  a=fmtp:100 mode-change-period=2; mode-change-capability=2;
> mode-change-neighbor=1; max-red=0
>  a=rtpmap:96 AMR/8000
>  a=fmtp:96 max-red=0
>  a=rtpmap:0 PCMU/8000
>  a=rtpmap:116 telephone-event/8000
>  a=ptime:20
>  a=maxptime:20
>  a=rtpmap:111 telephone-event/16000
>
> SDP in 200OK from VoLTE-phone with SDP as answer on initial INVITE
>  o=sip:+46708xxx...@ims.mnc008.mcc240.3gppnetwork.org 1611316978
> 0 IN IP6 2a02:1400:df:245d:435:1205:68e0:1ac3
> s=-
> c=IN IP6 2a02:1400:df:245d:435:1205:68e0:1ac3
> t=0 0
> a=sendrecv
> m=audio 49120 RTP/AVP 108 116
> b=AS:37
> b=RS:462
> b=RR:1387
> a=rtpmap:108 AMR/8000
> a=fmtp:108 mode-set=7; max-red=0; mode-change-capability=2;
> mode-change-period=2; mode-change-neighbor=1
> a=rtpmap:116 telephone-event/8000
> a=fmtp:116 0-15
> a=ptime:20
> a=maxptime:20
> a=sendrecv
>
>
> SDP in 200OK from VoLTE-phone with SDP offer as answer on INVITE without
> SDP
>   SDP PDU
>  v=0
>  o=sip:+46708...@ims.mnc008.mcc240.3gppnetwork.org 1611316978
> 1 IN IP6 2a02:1400:df:245d:435:1205:68e0:1ac3
>  s=-
>  c=IN IP6 2a02:1400:df:245d:435:1205:68e0:1ac3
>  t=0 0
>  a=sendrecv
>  m=audio 49120 RTP/AVP 109 104 110 102 108 105 100
>  b=AS:50
>  b=RS:625
>  b=RR:1875
>  a=rtpmap:109 EVS/16000
>  a=fmtp:109 br=13.2-24.4; bw=nb-wb; max-red=0; cmr=-1;
> ch-aw-recv=-1
>  a=rtpmap:104 AMR-WB/16000
>  a=fmtp:104 max-red=220; mode-change-capability=2
>  a=rtpmap:110 AMR-WB/16000
>  a=fmtp:110 octet-align=1; max-red=220; mode-change-capability=2
>  a=rtpmap:102 AMR/8000
>  a=fmtp:102 max-red=220; mode-change-capability=2
>  a=rtpmap:108 AMR/8000
>  a=fmtp:108 octet-align=1; max-red=220; mode-change-capability=2
>  a=rtpmap:105 telephone-event/16000
>  a=fmtp:105 0-15
>  a=rtpmap:100 telephone-event/8000
>  a=fmtp:100 0-15
>  a=ptime:20
>  a=maxptime:20
>  a=sendrecv
>
>
> ACK with SDP as answer on offer from VoLTE-phone
>
>   SDP PDU
>
>  v=0
>
>  o=- 805658488335263 1704590317 IN IP6 2A02:1400:10:1C::4
>
>  s=-
>
>  c=IN IP6 2a02:1400:10:1::4
>
>  t=0 0
>
>  m=audio 5394 RTP/AVP 104 105
>
>  

Re: [Sip-implementors] reuse of payload type

[Ranjit Avasarala]

Hi Sundbaum

Here the B side should adapt and change the common codec list to suit the
one received.  so change 100 to AMR/8000. Then the call will be
successful.

Regards
Ranjit


On Fri, Jan 22, 2021 at 6:56 AM Sundbaum Per-Johan (Telenor Sverige AB) <
per-johan.sundb...@telenor.se> wrote:

> Hi !
>
> I have a call scenario where I would appreciate opinions on which side is
> most correct or perhaps least incorrect !
>
> Call is from external operator, but the interesting part is between pCSCF
> and a VoLTE-phone.
> (the logs is from between pCSCF and the VoLTE-phone)
>
> pCSCF sends initial INVITE with sdp to UAS(VoLTE-phone)
>   SDP PDU
>  v=0
>  o=- 805658488335263 1704590316 IN IP6 2A02:1400:10:1C::4
>  s=-
>  c=IN IP6 2a02:1400:10:1::4
>  t=0 0
>  m=audio 5394 RTP/AVP 108 102 8 100 96 0 116 111
>  b=AS:141
>  a=rtpmap:108 AMR/8000
>  a=fmtp:108 mode-set=7; mode-change-period=2;
> mode-change-capability=2; mode-change-neighbor=1; max-red=0
>  a=rtpmap:102 AMR/8000
>  a=fmtp:102 mode-set=7; max-red=0
>  a=rtpmap:8 PCMA/8000
>  a=rtpmap:100 AMR/8000
>  a=fmtp:100 mode-change-period=2; mode-change-capability=2;
> mode-change-neighbor=1; max-red=0
>  a=rtpmap:96 AMR/8000
>  a=fmtp:96 max-red=0
>  a=rtpmap:0 PCMU/8000
>  a=rtpmap:116 telephone-event/8000
>  a=ptime:20
>  a=maxptime:20
>  a=rtpmap:111 telephone-event/16000
> later in same dialog an AS sends re-INVITE without SDP which results in
> 200OK answer from UAS(VoLTE-phone) with SDP
>
>   SDP PDU
>  v=0
>  o=sip:+46708...@ims.mnc008.mcc240.3gppnetwork.org 1611316978
> 1 IN IP6 2a02:1400:df:245d:435:1205:68e0:1ac3
>  s=-
>  c=IN IP6 2a02:1400:df:245d:435:1205:68e0:1ac3
>  t=0 0
>  a=sendrecv
>  m=audio 49120 RTP/AVP 109 104 110 102 108 105 100
>  b=AS:50
>  b=RS:625
>  b=RR:1875
>  a=rtpmap:109 EVS/16000
>  a=fmtp:109 br=13.2-24.4; bw=nb-wb; max-red=0; cmr=-1;
> ch-aw-recv=-1
>  a=rtpmap:104 AMR-WB/16000
>  a=fmtp:104 max-red=220; mode-change-capability=2
>  a=rtpmap:110 AMR-WB/16000
>  a=fmtp:110 octet-align=1; max-red=220; mode-change-capability=2
>  a=rtpmap:102 AMR/8000
>  a=fmtp:102 max-red=220; mode-change-capability=2
>  a=rtpmap:108 AMR/8000
>  a=fmtp:108 octet-align=1; max-red=220; mode-change-capability=2
>  a=rtpmap:105 telephone-event/16000
>  a=fmtp:105 0-15
>  a=rtpmap:100 telephone-event/8000
>  a=fmtp:100 0-15
>  a=ptime:20
>  a=maxptime:20
>  a=sendrecv
>
>
> As you can see the offer in initial INVITE have payload type 100:
> a=rtpmap:100 AMR/8000
> The offer in 200OK also have payload-type 100, but now it is: a=rtpmap:100
> telephone-event/8000
>
> I believe that this is causing failure when B-side (VoLTE-phone) is
> sending TelephoneEvent(DTMF) to A-side (UAC)
>
> Do you think A-side should adapt or maybe reject the offer in 200OK or do
> something else ?
>
>
> RFC3264  8.3.2
>"However, in the case of RTP, the mapping from a particular dynamic
> payload type
>number to a particular codec within that media stream MUST NOT change
>for the duration of a session.  For example, if A generates an offer
>with G.711 assigned to dynamic payload type number 46, payload type
>number 46 MUST refer to G.711 from that point forward in any offers
>or answers for that media stream within the session. "
>
>
> BR/pj
>
>
> Sensitivity: Internal
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Sip-implementors Digest, Vol 81, Issue 4

[Ranjit Avasarala]

Thank you

Regards
Ranjit

On Fri, Jan 8, 2021 at 10:40 AM Jonathan Lennox 
wrote:

> I am the list administrator, and I've removed this user.  Sorry about the
> inconvenience!
>
> On Friday, January 8 2021, "Alex Balashov" wrote to "
> sip-implementors@lists.cs.columbia.edu" saying:
>
> > I am not a list administrator, but speaking as a civilian:
> >
> > I think we have been patient, but the time is nigh to mute this
> subscriber.
> >
> > On 1/8/21 1:12 AM, supp...@advisory24.vip wrote:
> > > Hi Sip-implementors,   May I have your order number please? And
> please offer the email address and full name that you filled in when you
> made this order on our website.   So I can check it for you.  Cathy Lin
> > >
> > >  On
> > >  Fri, 8 Jan at  1:23 AM
> > >  ,  supp...@advisory24.vip
>   wrote:
> > >
> > > Thank you for contacting us!
> > > We have received the email.
> > > We are really sorry that we're off work now.
> > > Our working time is from 10am to 7pm (GMT 9), Mon to Fri.
> > > Please do not worry.
> > > We will arrange a dedicated customer service to solve your problem
> within 12 hours.
> > > We will try our best to help you.
> > > Have a nice day!
> > >
> > >
> > >
> > >
> > > ___
> > > Sip-implementors mailing list
> > > Sip-implementors@lists.cs.columbia.edu
> > > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> > >
> >
> > --
> > Alex Balashov | Principal | Evariste Systems LLC
> >
> > Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
> > Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
> > ___
> > Sip-implementors mailing list
> > Sip-implementors@lists.cs.columbia.edu
> > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
> --
> Jonathan Lennox
> len...@cs.columbia.edu
> sip-implementors-ow...@cs.columbia.edu
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] RFC 4028: SessionTimer negotiation using Early Update

[Ranjit Avasarala]

yes it should

On Mon, Jan 4, 2021 at 9:39 AM akashdeep vishnoi 
wrote:

> Hi,
>
> I am sending an Early Update request from UAC/UAS with changed
> Session-Expire timer and refresher.
> Should this Session Expire header value in Early Update request need to
> follow the rules defined in RFC 4028 for response.
>
> Thanks,
> Aakash
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Errata ID: 4744 for RFC 4028: Session Expire timer value can be changed?

[Ranjit Avasarala]

Yes UAS can change Session-Expires value.  See Section 9 in RFC 4028

Regards
Ranjit

On Fri, Dec 4, 2020 at 12:37 PM akashdeep vishnoi 
wrote:

> Hi Ranjit
>
> My question is: can Session-Expire value be changed by 2xx response or an
> early update request in call-setup phase?
>
> Errata ID: 4744 :
> *"A UAC starts by sending an INVITE. This includes a Supported header
> field with the option tag 'timer', indicating support for this extension.If
> UAC or UAS knows one negotiation of session timer is ongoing, it SHALL not
> start a new one."*
>
> As it has mentioned that 'it shall not start a new one'. Does it meant not
> to change the Session-Expire value if it is not below the minimum time?
>
> Thanks,
> Aakash
>
> On Fri, Dec 4, 2020 at 11:49 PM Ranjit Avasarala 
> wrote:
>
>> Hi Akash
>>
>> The UAS does respond to INVITE with Supported: timer, with a 4xx if the
>> interval is too short or responds with a 2xx.  Why do you think there
>> should be an early update? u mean a 1xx response?
>>
>> On Fri, Dec 4, 2020 at 12:05 PM akashdeep vishnoi <
>> akashanshu...@gmail.com> wrote:
>>
>>> In initial Invite request, UAC is sending a Session-Expires header.
>>> After receiving this request, UAS will know that session timer negotiation
>>> is ongoing.
>>> Can UAS send an early update with a different value in Session-Expires?
>>>
>>> Thanks,
>>> Aakash
>>>
>>> On Fri, 4 Dec 2020, 22:40 Ranjit Avasarala, 
>>> wrote:
>>>
>>>> Hi Aakash
>>>>
>>>> how will UAC or UAS know if another negotiation for session timer is
>>>> ongoing? do u mean multiple INVITEs are sent from UAC?
>>>>
>>>> Regards
>>>> Ranjit
>>>>
>>>> On Fri, Dec 4, 2020 at 11:01 AM akashdeep vishnoi <
>>>> akashanshu...@gmail.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I have a little confusion in this :
>>>>> 
>>>>> Errata ID: 4744
>>>>> Status: Reported
>>>>> Type: Technical
>>>>> Publication Format(s) : TEXT
>>>>> Reported By: Chao Wang
>>>>> Date Reported: 2016-07-19
>>>>>
>>>>> Section 3 says:
>>>>>  A UAC starts by sending an INVITE. This includes a Supported header
>>>>> field
>>>>> with the option tag 'timer', indicating support for this extension
>>>>>
>>>>> It should say:
>>>>> A UAC starts by sending an INVITE. This includes a Supported header
>>>>> field
>>>>> with the option tag 'timer', indicating support for this extension.If
>>>>> UAC
>>>>> or UAS knows one negotiation of session timer is ongoing, it SHALL not
>>>>> start a new one.
>>>>>
>>>>>
>>>>>
>>>>> ---
>>>>> As per above explanation, I want to know if* Session Expire timer
>>>>> value can
>>>>> be changed by UAS/UAC by sending early UPDATE* before Call is
>>>>> established
>>>>> when INVITE request already has one timer value.
>>>>>
>>>>> Thanks,
>>>>> Aakash
>>>>> ___
>>>>> Sip-implementors mailing list
>>>>> Sip-implementors@lists.cs.columbia.edu
>>>>> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>>>>>
>>>>
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Errata ID: 4744 for RFC 4028: Session Expire timer value can be changed?

[Ranjit Avasarala]

Hi Akash

The UAS does respond to INVITE with Supported: timer, with a 4xx if the
interval is too short or responds with a 2xx.  Why do you think there
should be an early update? u mean a 1xx response?

On Fri, Dec 4, 2020 at 12:05 PM akashdeep vishnoi 
wrote:

> In initial Invite request, UAC is sending a Session-Expires header. After
> receiving this request, UAS will know that session timer negotiation is
> ongoing.
> Can UAS send an early update with a different value in Session-Expires?
>
> Thanks,
> Aakash
>
> On Fri, 4 Dec 2020, 22:40 Ranjit Avasarala,  wrote:
>
>> Hi Aakash
>>
>> how will UAC or UAS know if another negotiation for session timer is
>> ongoing? do u mean multiple INVITEs are sent from UAC?
>>
>> Regards
>> Ranjit
>>
>> On Fri, Dec 4, 2020 at 11:01 AM akashdeep vishnoi <
>> akashanshu...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I have a little confusion in this :
>>> 
>>> Errata ID: 4744
>>> Status: Reported
>>> Type: Technical
>>> Publication Format(s) : TEXT
>>> Reported By: Chao Wang
>>> Date Reported: 2016-07-19
>>>
>>> Section 3 says:
>>>  A UAC starts by sending an INVITE. This includes a Supported header
>>> field
>>> with the option tag 'timer', indicating support for this extension
>>>
>>> It should say:
>>> A UAC starts by sending an INVITE. This includes a Supported header field
>>> with the option tag 'timer', indicating support for this extension.If UAC
>>> or UAS knows one negotiation of session timer is ongoing, it SHALL not
>>> start a new one.
>>>
>>>
>>>
>>> ---
>>> As per above explanation, I want to know if* Session Expire timer value
>>> can
>>> be changed by UAS/UAC by sending early UPDATE* before Call is established
>>> when INVITE request already has one timer value.
>>>
>>> Thanks,
>>> Aakash
>>> ___
>>> Sip-implementors mailing list
>>> Sip-implementors@lists.cs.columbia.edu
>>> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>>>
>>
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Errata ID: 4744 for RFC 4028: Session Expire timer value can be changed?

[Ranjit Avasarala]

Hi Aakash

how will UAC or UAS know if another negotiation for session timer is
ongoing? do u mean multiple INVITEs are sent from UAC?

Regards
Ranjit

On Fri, Dec 4, 2020 at 11:01 AM akashdeep vishnoi 
wrote:

> Hi,
>
> I have a little confusion in this :
> 
> Errata ID: 4744
> Status: Reported
> Type: Technical
> Publication Format(s) : TEXT
> Reported By: Chao Wang
> Date Reported: 2016-07-19
>
> Section 3 says:
>  A UAC starts by sending an INVITE. This includes a Supported header field
> with the option tag 'timer', indicating support for this extension
>
> It should say:
> A UAC starts by sending an INVITE. This includes a Supported header field
> with the option tag 'timer', indicating support for this extension.If UAC
> or UAS knows one negotiation of session timer is ongoing, it SHALL not
> start a new one.
>
>
>
> ---
> As per above explanation, I want to know if* Session Expire timer value can
> be changed by UAS/UAC by sending early UPDATE* before Call is established
> when INVITE request already has one timer value.
>
> Thanks,
> Aakash
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] sending Originating Charge Area as part of SIP message

[Ranjit Avasarala]

Hi Harshith

Charging correlation among different operators is achieved through Inter
Operator Identifier which is a globally unique identifier shared between
operator networks. The originating IOI and terminating IOI are exchanged by
the SIP request and response messages. The originating IOI is inserted by
the originating CSCF in the P-Charging-Vector in SIP INVITE or other SIP
requests.  Similarly terminating CSCF inserts the terminating IOI in SIP
responses in the P-Charging-Vector header

Regards
Ranjit

On Thu, Jul 2, 2020 at 7:21 AM Harshith Mulky 
wrote:

> Hello Experts,
>
> I want to send Originating Charge Area as part of SIP INVITE.
> How can we achieve this in SIP?
>
> Thanks
> Harshith
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Query on SIM swap

[Ranjit Avasarala]

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
> >
> > 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 is switched off,
> > *the USIM cardis removed from the UE* or the EPS capability of the UE is
> > disabled or the UE wishes to detach for non-EPS services
> >
> > As per FCM0.1 VoLTE Service Description and Implementation Guidelines
> >
> > 3.2.2 VoLTE UE Initiated Detach and IMS Deregistration
> > 3.2.2.1 General
> > *A VoLTE UE shall automatically deregister from IMS before performing an
> > LTE Detach*
> >
> >
> > Even we have seen use-cases where there are services linked with SIM ,and
> > UE can do refresh registration removing those capabilities
> > when SIM is removed .
> >
> > SIM swap anyway will be taken care if UE does IMS deregistration or
> > refresh-registration while SIM is removed.
> >
> > Hope this helps.
> >
> > Regards
> > Ankur Bansal
> >
> >
> > On Sun, May 3, 2020 at 8:37 PM Ranjit Avasarala 
> > wrote:
> >
> >> 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 sends SAA with DIAMETER_UNABLE_TO_COMPLY error.  CSCF translates
> this
> >> error to 500 Internal Server Error.
> >> So is this the expected behavior?
> >>
> >> Regards
> >> Ranjit
> >>
> >> On Sun, May 3, 2020 at 9:07 PM Dale R. Worley 
> wrote:
> >>
> >>> 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 PSTN telephone, I would expect that
> >> if
> >>> you change the SIM on a UE, the UE would register for the new DN.
> >>>
> >>> In SIP, the From address in an INVITE is not necessarily connected with
> >>> any AOR that the UE registers for.  But in a PSTN telephone, I would
> >>> expect it to use the SIM's DN as the From URI.
> >>>
> >>> Dale
> >>>
> >> ___
> >> Sip-implementors mailing list
> >> Sip-implementors@lists.cs.columbia.edu
> >> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> >>
> > ___
> > Sip-implementors mailing list
> > Sip-implementors@lists.cs.columbia.edu
> > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> >
>
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Query on SIM swap

[Ranjit Avasarala]

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 sends SAA with DIAMETER_UNABLE_TO_COMPLY error.  CSCF translates this
error to 500 Internal Server Error.
So is this the expected behavior?

Regards
Ranjit

On Sun, May 3, 2020 at 9:07 PM Dale R. Worley  wrote:

> 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 PSTN telephone, I would expect that if
> you change the SIM on a UE, the UE would register for the new DN.
>
> In SIP, the From address in an INVITE is not necessarily connected with
> any AOR that the UE registers for.  But in a PSTN telephone, I would
> expect it to use the SIM's DN as the From URI.
>
> Dale
>
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

[Sip-implementors] Query on SIM swap

[Ranjit Avasarala]

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
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

[Sip-implementors] Query on 500 Server Internal Error

[Ranjit Avasarala]

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
..
Reason:  Insufficient Bearer Resources

but the usage of Reason header is not very common and is optional.

SO I would like to know if there is any specification that mandates Reason
header in 500 response so that the entities receiving it would know the
reason for 500

Thank you
Ranjit
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Usage of "User-Agent" in SIP responses

[Ranjit Avasarala]

Hi Paul, Maxim

I agree with both and from the implementations i have seen so far, I see
User-Agent header being inserted by UE devices like smartphones : e.g.
User-Agent: LG  IMS client: 6.0  and Server header is inserted by the
intermediate servers like CSCF, AS, MRF, etc:  E.g. Server: CSCF and
softclients use either User-Agent or Server interchangeably

Regards
Ranjit



On Tue, Apr 28, 2020 at 12:35 PM Paul Kyzivat  wrote:

> On 4/28/20 1:08 PM, Maxim Sobolev wrote:
> > Hi,
> >
> > I've noticed that in the last few years few implementations have gained
> > popularity who use User-Agent in both requests and responses. Instead of
> > User-Agent in requests and Server in responses which I always believed
> > (perhaps incorrectly) to be the right way of doing it. The argument there
> > is that "oh, our implementation is an endpont/B2BUA, not an UAS".  The
> > question hence is it my reading of RFC wrong or theirs? Thanks!
>
>  From 3261:
>
> The Server header field contains information about the software used
> by the UAS to handle the request.
> ...
> The User-Agent header field contains information about the UAC
> originating the request.
>
> And note that UAC and UAS are *roles*. If you initiating (not
> forwarding) a SIP request then you are, at that moment, acting as a UAC.
> And if you are initiating (not forwarding) a SIP response then you are
> acting as a UAS. In practice it is really hard (probably impossible) to
> find anything that is purely a UAC or UAS.
>
> So the usage you are seeing is *wrong*.
>
> This gets hazy with B2BUAs. Note that they have no official standing in
> 3261. As far as 3261 is concerned  something that thinks of itself as a
> B2BUA is just two sip devices lashed together. When the B2BUA receives a
> request on one side it is acting as a UAS and when it sends it out the
> other side it is acting as a UAC. In principle that should be governing
> its use of User-Agent and Server on each side. But often they try to act
> as a Proxy. (Except when doing something that a Proxy isn't permitted to
> do.) I think they hand wave around this by claiming that they are
> sometimes acting as Proxies and other times are acting as UAs and so
> pick whichever suits them when arguing that they are compliant.
>
> Thanks,
> Paul
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Server can not relate ACK to the 200 OK

[Ranjit Avasarala]

Hi Peter

Could you send the call trace as a pcap file?

Thank you
Ranjit

On Thu, Feb 20, 2020 at 9:16 AM Dr. Peter Sties  wrote:

> Hi Ranjit,
>
>
>
> Thank you for the suggestion. Currently, the ACK contains the same 5
> methods in the allow as the INVITE. In both cases, it is:
>
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
>
>
>
> Maybe it is not so good readable in the mail. The long list of allowed
> methods is from the other server.
>
>
>
> Thanks,
>
>
>
> Peter
>
>
>
>
>
>
>
>
> Am Donnerstag, 20. Februar 2020, 16:07:38 CET schrieb Ranjit Avasarala:
>
> Hi Peter
>
>
> the Allow header in ACK contains only 4 methods - it should contain all
> the methods (same as INVITE).   Modify the ACK request's Allow header to
> include additional methods and re-test
>
>
> Regards
>
> Ranjit
>
>
> On Thu, Feb 20, 2020 at 4:05 AM Dr. Peter Sties  wrote:
>
> Hi Richard,
>
> Thanks for the suggestion. The messages between the servers are
> transferred
> via a TCP connection (and all to the same IP address). So I think it
> should be
> well received  by the server.
>  I am still clueless...
>
> Thanks,
>
> Peter
>
>
> Am Donnerstag, 20. Februar 2020, 11:00:56 CET schrieb Richard Phernambucq:
> > Hi,
> >
> > Header-wise your ACK appears OK.
> >
> > I suspect your problem is that the destination address for the ACK
> > (200.200.200.200) is not routable from your SIP-server. This might
> > explain why the provider's server keeps retransmitting the response.
> >
> > BR,
> > Richard
> >
> > On 20-2-2020 10:39, Dr. Peter Sties wrote:
> > > Hi !
> > >
> > > I have some problems within a SIP trunc where our SIP-server talks
> > > directly to different provider SIP servers. One of these servers on the
> > > other side does not recognize our ACK to the 200 OK message. The other
> > > server keeps on repeating the 200 OK message.
> > >
> > > I have gone through all the header fields and compared it with the SIP
> > > specification and examples but I do not have clue why the other side
> does
> > > not accept our ACK. I would be great if someone can have a look at it
> and
> > > give me some hints.
> > >
> > > Here is the SIP-Trace:
> > > 2020-02-10 13:04:27.467 <-- send SIP TO 200.200.200.200  653 bytes
> > > INVITE sip:+491234567@200.200.200.200 SIP/2.0
> > > Via: SIP/2.0/TCP 100.100.100.100:5060;branch=z9hG4bKDGT5EGVPVDE4I146
> > > From:
> > > ;tag=C8UF20CAKNLTLJ18
> > > To: 
> > > Call-ID: E4COR3MNVB8AK908
> > > CSeq: 1 INVITE
> > > Contact: 
> > > Max-Forwards: 70
> > > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
> > > Content-Type: application/sdp
> > > Content-Length: 206
> > >
> > > v=0
> > > o=om 73848 1 IN IP4 100.100.100.100
> > > s=call
> > > c=IN IP4 100.100.100.100
> > > t=0 0
> > > m=audio 50012 RTP/AVP 8 101
> > > a=rtpmap:8 PCMA/8000
> > > a=rtpmap:101 telephone-event/8000
> > > a=fmtp:101 0-15
> > > a=ptime:20
> > > a=sendrecv
> > >
> > > 2020-02-10 13:04:27.481 --> rcvd SIP FROM TCP 1  288 bytes
> > > SIP/2.0 100 Trying
> > > Via: SIP/2.0/TCP 100.100.100.100:5060;branch=z9hG4bKDGT5EGVPVDE4I146
> > > From:
> > > ;tag=C8UF20CAKNLTLJ18
> > > To: 
> > > Call-ID: E4COR3MNVB8AK908
> > > CSeq: 1 INVITE
> > > Content-Length: 0
> > >
> > >
> > > 2020-02-10 13:04:28.473 --> rcvd SIP FROM TCP 1  729 bytes
> > > SIP/2.0 183 Session Progress
> > > Via: SIP/2.0/TCP 100.100.100.100:5060;branch=z9hG4bKDGT5EGVPVDE4I146
> > > From:
> > > ;tag=C8UF20CAKNLTLJ18
> > > To:
> > >  200:5060;user=phone>;tag=SDuhhca99-6ossrg8l-
> > > CC-57
> > > Call-ID: E4COR3MNVB8AK908
> > > CSeq: 1 INVITE
> > > Contact: 
> > > Allow:
> > >
> INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,SUBSCRIBE,NOTIFY,UPDATE,
> > > MESSAGE,REFER Content-Length: 223
> > > Content-Type: application/sdp
> > >
> > > v=0
> > > o=HuaweiSoftX3000 27670846 27670846 IN IP4 200.200.200.200
> > > s=Sip Call
> > > c=IN IP4 200.200.200.200
> > > t=0 0
> > > m=audio 22978 RTP/AVP 8 101
> > > a=rtpmap:8 PCMA/8000
> > > a=rtpmap:101 telephone-event/8000
> > > a=ptime:20
> > > a=fmtp:101 0-15
> > >
> > &g

Re: [Sip-implementors] Server can not relate ACK to the 200 OK

[Ranjit Avasarala]

Hi Peter

the Allow header in ACK contains only 4 methods - it should contain all the
methods (same as INVITE).   Modify the ACK request's Allow header to
include additional methods and re-test

Regards
Ranjit

On Thu, Feb 20, 2020 at 4:05 AM Dr. Peter Sties  wrote:

> Hi Richard,
>
> Thanks for the suggestion. The messages between the servers are
> transferred
> via a TCP connection (and all to the same IP address). So I think it
> should be
> well received  by the server.
>  I am still clueless...
>
> Thanks,
>
> Peter
>
>
> Am Donnerstag, 20. Februar 2020, 11:00:56 CET schrieb Richard Phernambucq:
> > Hi,
> >
> > Header-wise your ACK appears OK.
> >
> > I suspect your problem is that the destination address for the ACK
> > (200.200.200.200) is not routable from your SIP-server. This might
> > explain why the provider's server keeps retransmitting the response.
> >
> > BR,
> > Richard
> >
> > On 20-2-2020 10:39, Dr. Peter Sties wrote:
> > > Hi !
> > >
> > > I have some problems within a SIP trunc where our SIP-server talks
> > > directly to different provider SIP servers. One of these servers on the
> > > other side does not recognize our ACK to the 200 OK message. The other
> > > server keeps on repeating the 200 OK message.
> > >
> > > I have gone through all the header fields and compared it with the SIP
> > > specification and examples but I do not have clue why the other side
> does
> > > not accept our ACK. I would be great if someone can have a look at it
> and
> > > give me some hints.
> > >
> > > Here is the SIP-Trace:
> > > 2020-02-10 13:04:27.467 <-- send SIP TO 200.200.200.200  653 bytes
> > > INVITE sip:+491234567@200.200.200.200 SIP/2.0
> > > Via: SIP/2.0/TCP 100.100.100.100:5060;branch=z9hG4bKDGT5EGVPVDE4I146
> > > From:
> > > ;tag=C8UF20CAKNLTLJ18
> > > To: 
> > > Call-ID: E4COR3MNVB8AK908
> > > CSeq: 1 INVITE
> > > Contact: 
> > > Max-Forwards: 70
> > > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
> > > Content-Type: application/sdp
> > > Content-Length: 206
> > >
> > > v=0
> > > o=om 73848 1 IN IP4 100.100.100.100
> > > s=call
> > > c=IN IP4 100.100.100.100
> > > t=0 0
> > > m=audio 50012 RTP/AVP 8 101
> > > a=rtpmap:8 PCMA/8000
> > > a=rtpmap:101 telephone-event/8000
> > > a=fmtp:101 0-15
> > > a=ptime:20
> > > a=sendrecv
> > >
> > > 2020-02-10 13:04:27.481 --> rcvd SIP FROM TCP 1  288 bytes
> > > SIP/2.0 100 Trying
> > > Via: SIP/2.0/TCP 100.100.100.100:5060;branch=z9hG4bKDGT5EGVPVDE4I146
> > > From:
> > > ;tag=C8UF20CAKNLTLJ18
> > > To: 
> > > Call-ID: E4COR3MNVB8AK908
> > > CSeq: 1 INVITE
> > > Content-Length: 0
> > >
> > >
> > > 2020-02-10 13:04:28.473 --> rcvd SIP FROM TCP 1  729 bytes
> > > SIP/2.0 183 Session Progress
> > > Via: SIP/2.0/TCP 100.100.100.100:5060;branch=z9hG4bKDGT5EGVPVDE4I146
> > > From:
> > > ;tag=C8UF20CAKNLTLJ18
> > > To:
> > >  200:5060;user=phone>;tag=SDuhhca99-6ossrg8l-
> > > CC-57
> > > Call-ID: E4COR3MNVB8AK908
> > > CSeq: 1 INVITE
> > > Contact: 
> > > Allow:
> > >
> INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,SUBSCRIBE,NOTIFY,UPDATE,
> > > MESSAGE,REFER Content-Length: 223
> > > Content-Type: application/sdp
> > >
> > > v=0
> > > o=HuaweiSoftX3000 27670846 27670846 IN IP4 200.200.200.200
> > > s=Sip Call
> > > c=IN IP4 200.200.200.200
> > > t=0 0
> > > m=audio 22978 RTP/AVP 8 101
> > > a=rtpmap:8 PCMA/8000
> > > a=rtpmap:101 telephone-event/8000
> > > a=ptime:20
> > > a=fmtp:101 0-15
> > >
> > > 2020-02-10 13:04:29.421 --> rcvd SIP FROM TCP 1  720 bytes
> > > SIP/2.0 180 Ringing
> > > Via: SIP/2.0/TCP 100.100.100.100:5060;branch=z9hG4bKDGT5EGVPVDE4I146
> > > From:
> > > ;tag=C8UF20CAKNLTLJ18
> > > To:
> > >  200:5060;user=phone>;tag=SDuhhca99-6ossrg8l-
> > > CC-57
> > > Call-ID: E4COR3MNVB8AK908
> > > CSeq: 1 INVITE
> > > Allow:
> > >
> INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,SUBSCRIBE,NOTIFY,UPDATE,
> > > MESSAGE,REFER Contact: 
> > > Content-Length: 223
> > > Content-Type: application/sdp
> > >
> > > v=0
> > > o=HuaweiSoftX3000 27670846 27670847 IN IP4 200.200.200.200
> > > s=Sip Call
> > > c=IN IP4 200.200.200.200
> > > t=0 0
> > > m=audio 22978 RTP/AVP 8 101
> > > a=rtpmap:8 PCMA/8000
> > > a=rtpmap:101 telephone-event/8000
> > > a=ptime:20
> > > a=fmtp:101 0-15
> > >
> > > 2020-02-10 13:04:33.781 --> rcvd SIP FROM TCP 1  782 bytes
> > > SIP/2.0 200 OK
> > > Via: SIP/2.0/TCP 100.100.100.100:5060;branch=z9hG4bKDGT5EGVPVDE4I146
> > > From:
> > > ;tag=C8UF20CAKNLTLJ18
> > > To:
> > >  200:5060;user=phone>;tag=SDuhhca99-6ossrg8l-
> > > CC-57
> > > Call-ID: E4COR3MNVB8AK908
> > > CSeq: 1 INVITE
> > > Allow:
> > >
> INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,SUBSCRIBE,NOTIFY,UPDATE,
> > > MESSAGE,REFER P-Asserted-Identity:
> > > 
> > > Contact: 
> > > Content-Length: 223
> > > Content-Type: application/sdp
> > >
> > > v=0
> > > o=HuaweiSoftX3000 27670846 27670848 IN IP4 200.200.200.200
> > > s=Sip Call
> > > c=IN IP4 200.200.200.200
> > > t=0 0
> > > m=audio 22978 RTP/AVP 8 101
> > > a=rtpmap:8 PCMA/8000
> > > a=rtpmap:101 telephone-eve

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

[Ranjit Avasarala]

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
> > 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 translated the SS7 message to SIP INVITE and put
> the
> > codecs it supports.  So since the terminating device does not support any
> > of the listed codecs in SIP INVITE SDP offer, it responded with 488
> response
> >
> > So my query is - is there a way the terminating device could indicate the
> > list of codecs it supports in 488 response?
>
> RFC3261:
>
> 21.4.26 488 Not Acceptable Here
>
> The response has the same meaning as 606 (Not Acceptable), but only
> applies to the specific resource addressed by the Request-URI and the
> request may succeed elsewhere.
>
> A message body containing a description of media capabilities MAY be
> present in the response, which is formatted according to the Accept
> header field in the INVITE (or application/sdp if not present), the
> same as a message body in a 200 (OK) response to an OPTIONS request.
>
> Thanks,
> Paul
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

[Sip-implementors] Query on SIP 488 response

[Ranjit Avasarala]

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 translated the SS7 message to SIP INVITE and put the
codecs it supports.  So since the terminating device does not support any
of the listed codecs in SIP INVITE SDP offer, it responded with 488 response

So my query is - is there a way the terminating device could indicate the
list of codecs it supports in 488 response?

Thanks
Ranjit
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

[Sip-implementors] Proposal for a mew SIP 4xx Error code

[Ranjit Avasarala]

Hello all

Many times I experienced scenarios where SIP requests (e.g. INVITE, PUBLISH
or PRACK or any other) have either invalid parameters in the header or a
particular header is missing in the request or the header value is
incomplete.  Some e.gs are

   - SIP Route header in INVITE contains additional "lr" parameter.
   Ideally, "lr" parameter needs to be associated with a particular route -
   i.e. sip URI
   - the Accept header is missing in SIP PUBLISH
   - the Allow header misses UPDATE method
   - .  many more

Currently, in all the above cases the SIP Proxy server that receives the
request, responds with a 400 Bad Request.
Though 400 Bad Request is acceptable given that there is some issue in the
SIP request, a more detailed error would be more useful - as sometimes
interpreting 400 Bad Request is harder
E.g.
a  4xx Invalid header/parameter may be more appropriate with reason
E.g. if there is additional "lr" parameter in SIP INVITE, then the proxy
can return a 4xx Invalid Header/parameter with Reason:  SIP code=4xx;
Text="Invalid lr parameter in Route header"

Let me know your thoughts on if this proposal can be taken forward as an
Internet draft.

Thank you
Ranjit
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] PSTN parameters in the FROM INVITE

[Ranjit Avasarala]

Hi Guillermo

From Sonus documentation:

Certain legacy signaling parameters (e.g., TMR) require end-to-end
delivery. While SIP-I is the preferred way to transport PSTN information
end-to-end, there are certain partners and customers that do not support
SIP-I and yet
require delivery of these parameters. Sonus supports a parameter in the
From header that transports certain of the PSTN parameters.  This is the
pstn-params parameter

So here the 8084818088 is the calling number.

Hope this info helps

Regards
Ranjit

On Fri, Oct 11, 2019 at 12:51 PM Zuñiga, Guillermo <
guillermo.zun...@cwpanama.com> wrote:

> Thanks a lot.
>
>
>
> Do you have any idea what means the value 8084818088?
>
>
>
> Regards,
>
> Guillermo
>
>
>
> *De:* Ranjit Avasarala [mailto:ranjitka...@gmail.com]
> *Enviado el:* Friday, October 11, 2019 12:42 PM
> *Para:* Zuñiga, Guillermo; Sip-implementors@lists.cs.columbia.edu
> *Asunto:* Re: [Sip-implementors] PSTN parameters in the FROM INVITE
>
>
>
> Hi Guillermo
>
>
>
> This link may help -
> https://support.sonus.net/display/SBXDOC61/Sip+Headers+And+Parameters+-+Flags
>
>
>
>
>
> On Thu, Oct 10, 2019 at 3:45 PM Zuñiga, Guillermo <
> guillermo.zun...@cwpanama.com> wrote:
>
> Hi Fellows,
>
> I would like you can help me with the following:
>
> I was trying to look for information about what means the numbers that
> appear in some cases in the FROM header of the INVITE with the following
> (pstn-params=8084818088).
>
> From:  ;pstn-params=8084818088>;tag=SDh25j501-gK0a3ed144
>
> Could you help to identify where I can get information about this? Cause
> in some case numbers are differents.
>
> Regards,
> Guillermo
> Thanks a lot.
>
>
>
>
>
> Guillermo Zuniga
> Especialista de Soporte Técnico
> Gerencia de Soporte Técnico
>
> P:  +507 263-6671   | +507 6670-0481
> E:  guillermo.zun...@cwpanama.com   |W: www.cwpanama.com
>
> [cid:65917c.png@84665ac2.46acfe6b]<https://www.cwpanama.com>
>
> [cid:793c69.png@c2454ba4.45b454f0]<https://www.facebook.com/masmovilpanama>
>[cid:3a8a49.png@3e0a5c55.49b80874] <https://twitter.com/masmovilpanama>
>[cid:d16d11.png@007e85ee.4aba660c] <
> https://www.instagram.com/masmovilpanama/>
>
>
>
>
>
>
> El contenido de este correo es confidencial y puede ser objeto de acciones
> legales.  Es dirigido solo para el o los destinatarios(s) nombrados
> anteriormente. Si no es mencionado como destinatario, no debe leer, copiar,
> revelar, reenviar o utilizar el contenido de este mensaje. Si ha recibido
> este correo por error, por favor notifique al remitente y proceda a borrar
> el mensaje y archivos adjuntos sin conservar copias.
>
> The information contained in this e-mail is confidential and may also be
> subject to legal privilege.  It is intended only for the recipient(s) named
> above.  If you are not named as a recipient, you must not read, copy,
> disclose, forward or otherwise use the information contained in this
> email.  If you have received this e-mail in error, please notify the sender
> immediately by reply e-mail and delete the message and any attachments
> without retaining any copies.
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
>
> Disclaimer:
> El contenido de este correo es confidencial y puede ser objeto de acciones
> legales. Es dirigido solo para el o los destinatarios(s) nombrados
> anteriormente. Si no es mencionado como destinatario, no debe leer, copiar,
> revelar, reenviar o utilizar el contenido de este mensaje. Si ha recibido
> este correo por error, por favor notifique al remitente y proceda a borrar
> el mensaje y archivos adjuntos sin conservar copias.
> The information contained in this e-mail is confidential and may also be
> subject to legal privilege. It is intended only for the recipient(s) named
> above. If you are not named as a recipient, you must not read, copy,
> disclose, forward or otherwise use the information contained in this email.
> If you have received this e-mail in error, please notify the sender
> immediately by reply e-mail and delete the message and any attachments
> without retaining any copies.
>   ­­
>
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] PSTN parameters in the FROM INVITE

[Ranjit Avasarala]

Hi Guillermo

This link may help -
https://support.sonus.net/display/SBXDOC61/Sip+Headers+And+Parameters+-+Flags


On Thu, Oct 10, 2019 at 3:45 PM Zuñiga, Guillermo <
guillermo.zun...@cwpanama.com> wrote:

> Hi Fellows,
>
> I would like you can help me with the following:
>
> I was trying to look for information about what means the numbers that
> appear in some cases in the FROM header of the INVITE with the following
> (pstn-params=8084818088).
>
> From:  ;pstn-params=8084818088>;tag=SDh25j501-gK0a3ed144
>
> Could you help to identify where I can get information about this? Cause
> in some case numbers are differents.
>
> Regards,
> Guillermo
> Thanks a lot.
>
>
>
>
>
> Guillermo Zuniga
> Especialista de Soporte Técnico
> Gerencia de Soporte Técnico
>
> P:  +507 263-6671   | +507 6670-0481
> E:  guillermo.zun...@cwpanama.com   |W: www.cwpanama.com
>
> [cid:65917c.png@84665ac2.46acfe6b]
>
> [cid:793c69.png@c2454ba4.45b454f0]
>[cid:3a8a49.png@3e0a5c55.49b80874] 
>[cid:d16d11.png@007e85ee.4aba660c] <
> https://www.instagram.com/masmovilpanama/>
>
>
>
>
>
>
> El contenido de este correo es confidencial y puede ser objeto de acciones
> legales.  Es dirigido solo para el o los destinatarios(s) nombrados
> anteriormente. Si no es mencionado como destinatario, no debe leer, copiar,
> revelar, reenviar o utilizar el contenido de este mensaje. Si ha recibido
> este correo por error, por favor notifique al remitente y proceda a borrar
> el mensaje y archivos adjuntos sin conservar copias.
>
> The information contained in this e-mail is confidential and may also be
> subject to legal privilege.  It is intended only for the recipient(s) named
> above.  If you are not named as a recipient, you must not read, copy,
> disclose, forward or otherwise use the information contained in this
> email.  If you have received this e-mail in error, please notify the sender
> immediately by reply e-mail and delete the message and any attachments
> without retaining any copies.
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Fwd: ue-addr parameter in SIP Contact header

[Ranjit Avasarala]

Hi Christer

Thank you.  Looking again and comparing both the Scenarios, I think in
Scenario-1, the GRUU is present while in Scenario-2, the GRUU is absent.
Does this make a difference in CSCF interpreting the Contact URI parameter?

Regards
Ranjit

On Mon, Oct 7, 2019 at 4:28 AM Christer Holmberg <
christer.holmb...@ericsson.com> wrote:

> Hi,
>
>
>
> Since there is no standard specification (AFAIK) specifying the usage
> ue-addr I think you would have to ask the S-CSCF vendor about the behavior.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> *From: *Ranjit Avasarala 
> *Date: *Monday, 7 October 2019 at 6.42
> *To: *Philipp Schöning , "
> Sip-implementors@lists.cs.columbia.edu" <
> Sip-implementors@lists.cs.columbia.edu>, Christer Holmberg <
> christer.holmb...@ericsson.com>, "pkyzi...@alum.mit.edu" <
> pkyzi...@alum.mit.edu>
> *Subject: *Re: [Sip-implementors] Fwd: ue-addr parameter in SIP Contact
> header
>
>
>
> Hi Philip
>
>
>
> Yes, I agree that connection and relation to UE are maintained by P-CSCF
> and S-CSCF does not need them.  But in some call scenarios, the S-CSCF
> connects to subsequent network elements like MRF and it is supposed to pass
> the "ue-addr" parameter it receives from P-CSCF (in Contact header) as is -
> without removing it
>
>
>
> E.g.  there are 2 scenarios
>
>
>
> Scenario-1:  INVITE from Access-SBC to S-CSCF with ue-addr:  Contact:
> *;+g.3gpp.icsi*
> -ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";video;mobility="fixed"
>
>
>
> Scenario-2:  INVITE from Interconnect SBC to S-CSCF with ue-addr: Contact:
> *;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";+g.3gpp.mid-call;+g.3gpp.srvcc-alerting;+g.3gpp.ps2cs-srvcc-orig-pre-alerting*
>
>
>
> In case of Scenario-1:  the S-CSCF is passing the ue-addr in Contact as is
> towards next hop but in Scenario-2, the S-CSCF is removing the ue-addr
> before passing the INVITE to next hop
>
>
>
> Question:  why is S-CSCF removing ue-addr parameter in Scenario-2 and not
> removing in Scenario-1?  Does the position of ue-addr parameter in Contact
> header matter?
>
>
>
> On Sun, Oct 6, 2019 at 12:00 PM Philipp Schöning 
> wrote:
>
> Hi Ranjit,
>
> I can't answer the question, but I have another question:
> Isn't the connection and relation to the UE maintained by the P-CSCF?
>
> From my perspective the S-CSCF does not have any relation to the UE.
>
> BR
> Philipp
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
>
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Fwd: ue-addr parameter in SIP Contact header

[Ranjit Avasarala]

Hi Philip

Yes, I agree that connection and relation to UE are maintained by P-CSCF
and S-CSCF does not need them.  But in some call scenarios, the S-CSCF
connects to subsequent network elements like MRF and it is supposed to pass
the "ue-addr" parameter it receives from P-CSCF (in Contact header) as is -
without removing it

E.g.  there are 2 scenarios

Scenario-1:  INVITE from Access-SBC to S-CSCF with ue-addr:  Contact:
*;+g.3gpp.icsi*
-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";video;mobility="fixed"

Scenario-2:  INVITE from Interconnect SBC to S-CSCF with ue-addr: Contact:
*;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";+g.3gpp.mid-call;+g.3gpp.srvcc-alerting;+g.3gpp.ps2cs-srvcc-orig-pre-alerting*

In case of Scenario-1:  the S-CSCF is passing the ue-addr in Contact as is
towards next hop but in Scenario-2, the S-CSCF is removing the ue-addr
before passing the INVITE to next hop

Question:  why is S-CSCF removing ue-addr parameter in Scenario-2 and not
removing in Scenario-1?  Does the position of ue-addr parameter in Contact
header matter?

On Sun, Oct 6, 2019 at 12:00 PM Philipp Schöning 
wrote:

> Hi Ranjit,
>
> I can't answer the question, but I have another question:
> Isn't the connection and relation to the UE maintained by the P-CSCF?
>
> From my perspective the S-CSCF does not have any relation to the UE.
>
> BR
> Philipp
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

[Sip-implementors] Fwd: ue-addr parameter in SIP Contact header

[Ranjit Avasarala]

Hello SIP experts

I have a scenario where, the S-CSCF is ignoring
ue-addr=x.y.z.a;transport=udp parameter in INVITE request.  Ignoring in the
sense that it is not adding the "ue-addr" parameter in the INVITE it
forwards to next hop

but in another scenario, when the "ue-addr" is of the format
ue-addr=x.y.z.x>  i.e there is no transport=udp parameter added, then the
S-CSCF is adding the "ue-addr" in the INVITE it forwards to next hop.

So what could be the issue - is it presence of transport=udp next to
ue-addr parameter that S-CSCF is not liking and ignoring?

Thank you
Ranjit
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors