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
Ra
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,
> Pe
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 ba
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
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
E 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 vo
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
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,
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 <
anus
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
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
UST 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.
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
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
ng 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
>
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
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
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 fo
*
>
> 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
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, wrot
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 :
>
> Errat
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 in
> > 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-registrat
stered
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
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
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
...
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
, 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
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 th
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 w
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
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 add
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
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 f
<
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
>
>
>
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)
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-a
37 matches
Mail list logo
