Dear All,
I have the problem where the customer is sending the BYE after 200 OK, but
my switch refused to identify the dialog and sent the SIP 481, and I feel
this is because of different TO tag.
SIP 200 OK in the correspondence of initial Invite.
*Switch to UAC*
From: "" ;tag=6H3KeXvvcFDQg
To:
Dear All,
I need the seniors help to understand the problem I am facing right now.
The problem is where one of my client doesn't send the ACK for 200 OK in
the correspondence of initial invite.
But at the same time when after sending multiple 200 OK, my switch sent the
BYE then immediately client
Hi Dale,
Thank you very much. Its clear now. I found one as well under 3261 under
Paragraph 15.
On Fri, Jun 9, 2017 at 8:04 PM, Dale R. Worley wrote:
> NK writes:
> > I am facing a strange scenario where my SBC is sending BYE before it
> > received 200 OK for initial in
Dear All,
I am facing a strange scenario where my SBC is sending BYE before it
received 200 OK for initial invite.
A = INVITE > B
A <=== 100 Giving a Try B
A <==100 Try B
A <==183 w/SDP==B
A <==183 w/SDP==B
A <==180 w/SDP
m tag and To tag as the ACK
> to the INVITE.
>
> On Fri, Aug 19, 2016 at 3:20 PM, NK wrote:
>
>> Dear All,
>>
>> As far as i know Branch Parameter in the VIA Header, must be unique for
>> every new transaction.
>>
>> Which means, when we send th
sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-
> > implementors-boun...@lists.cs.columbia.edu] On Behalf Of NK
> > Sent: Friday, August 19, 2016 3:20 PM
> > To: sip-implementors@lists.cs.columbia.edu
> > Subject: [Sip-implementors] Branch Header in BYE
> >
> > D
Dear All,
As far as i know Branch Parameter in the VIA Header, must be unique for
every new transaction.
Which means, when we send the BYE to any dialog, then the BRANCH parameter
will be different as compare the Initial invite.
However i cannot see any document which stating the same.
Can you
Dear All,
I have one call example where Session Expire in 200 Ok set to 600 Seconds.
But UAS never sent the UPDATE before this timer expire.
After 900 Seconds UAC is sending BYE because they were expecting the UPDATE
from UAS, since the refresher is uas.
Anyone faced this kind of problem where
/ Revert to Audio ReINVITE.
>
> We have seen this behavior with many T.38 vendors.
>
> Regards
> Tarun Gupta
>
>
> -Original Message-
> From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:
> sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of NK
&
> Puneet
>
> -Original Message-
> From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:
> sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of NK
> Sent: Friday, July 31, 2015 11:32 AM
> To: sip-implementors@lists.cs.columbia.edu
> Subject: [Sip-implemen
Dear All,
It is legal to send re-invite after sending T.38 when negotiation is
already done.
Below is the scenario.
UA -> INVITE
UA <--100 Trying
UA <--- 180 w/SDP
UA <--- 200 OK
UA --> (Re-invite for fax with T.38)
UA <--100 Trying
UA <---200 OK
*UA <--
s no knowledge of the dialog. Normally
> > a BYE
> >> should have been sent in one direction or the other when terminating the
> >> dialog. While it is possible that a BYE was sent and lost, it would then
> > have
> >> been retried several times. So it might
Dear All,
I need your help to understand a logic behind the session expires.
My doubt is.
--> Invite have "session-expire" header in Invite (from UAC to UAS)
--> UAS did not included "session-expire" header in 200 OK to the
correspondence of initial invite.
1) So in this case what we should as
Dear All,
I have a scenario where our vendor includes Q.850 in proviosnal response
(183 w/sDP) in every call scenerio, doesnt matter whether number is
invalid, busy, unlocatted.
In other words if they want to give us busy they will send 183 w/SDP and in
that they will add "reason header" and will
t using RFC 2833 [9]. Congestion
> control might necessitate changing to a lower rate codec based on
> feedback.
>
> There has been no change in the initially exchanged offer/answer. Vendor
> is using once of the codes already listed in the answer hence a new
> offer/an
; It doesn't matter what messages the offers and answers are carried it.
> Except of course that can be times when you aren't yet allowed to send
> another offer. During those periods you just have to cope with things as
> they are.
>
> Thanks,
> Paul
>
witch to a comfort
> noise codec. Or, if the user presses a number on the keypad, the
> agent might like to send that using RFC 2833 [9]. Congestion
> control might necessitate changing to a lower rate codec based on
> feedback.
>
> Thanks,
> Ashish
>
>
ed, it means that the offerer is capable of
> making use of any of those formats during the session. In other words, the
> answerer MAY change formats in the middle of the session, making use of any
> of the formats listed, without sending a new offer."
>
> Mike
>
> On 17 Ap
Dear All,
I am facing the problem where my vendor changed the codec in RTP
packet only. Below is the explanation to this issue.
1) We sent the Invite to vendor and Vendor replied 183 w/SDP along with
below m line. Also since its early media RTP started and agreed to use G729
Codec as below and UA
Dear All,
I am facing the problem where My switch is unable to forward the 183 w/SDP
which i am receiving from my vendor. When i checked the traces i noticed as
below which i never the patter in CONTACT header and niether i can found
any document.
Can you please help me to understand if this is t
Hi Brett,
Thanks a lot for your help.
On Thu, Feb 12, 2015 at 2:55 AM, Brett Tate wrote:
> > Can you pleae advise if we can send the re-invite with
> > new codec.
>
> You can offer it; however the UAS might reject it.
>
> RFC 3264 section 8 discusses session modification.
>
> RFC 6337 section 5
Dear All,
I have a query related to SIP-re-invite.
Can you pleae advise if we can send the re-invite with new codec.
Suppose initial offer had G729A and call established successfully after 200
OK. Now suppose if my UAC send the "reinivte" along with G711 or G729 AB or
annex=b" and there on G729A in
Dear All,
I have the call scenario where my customer is sending me 18 & 97 payload
type in media discription and customer is facing the voice break issues,
whereas the negotation was happened only on G729 Annexb=no.
Whereas if i dial over the same vendor i am using 18 & 101 RTP payload type
in SD
Mon, Jul 14, 2014 at 7:02 PM, Paul Kyzivat wrote:
> On 7/14/14 6:14 PM, NK wrote:
>
>> Dear All,
>>
>> I have query regarding the Session version in SDP. I know if we are making
>> any changes in SDP then from 183 to 200OK with SDP then there will be
>> incre
Dear All,
I have query regarding the Session version in SDP. I know if we are making
any changes in SDP then from 183 to 200OK with SDP then there will be
increment in session version from 183 to 200 OK
. However i have 2 doubt as below. Can you please help
me on this.
1) Is that Value should b
Hi Brett,
Thanks a lot for your help!!
Regards,
Nitin Kapoor
On Thu, Jul 10, 2014 at 1:27 PM, Brett Tate wrote:
> > is that 2~3 183 w/sdp is valid and call can be processed?
>
> Yes; it is valid. However, RFC 6337 recommends to not include the SDP.
>
> Maybe you will find the following snipp
Hi Brett,
I mean to say in second or third 183 w/SDP "TO" tag is same but "RSeq:
2779" is incrementing.
I am sorry but i am still not clear on second part, is that 2~3 183 w/sdp
is valid and call can be processed? As you mentioned if UAS sends the 183
w/SDP where it is requesting for PRACK again
Hi Brett,
Thanks a lot for your reply. Below is my understanding, please advise if it
is correct.
> I have call flow like where Vendor sends
> 183 w/SDP included Rseq and customer sents
> the PRACK and 200 OK from vendor.
>
> After that vendor is again sending 1~2
> 183 w/SDP where it is not chan
Dear All,
I have call flow like where Vendor sends 183 w/SDP included Rseq and
customer sents the PRACK and 200 OK from vendor.
After that vendor is again sending 1~2 183 w/SDP where it is not changing
anything in SDP but only asking for PRACK by sending RSEQ. I checked the
RFC , but cannot see a
Dear All,
We are getting the below FROM header from one of my client. Can you please
help me to get the answer on this, whether this is valid format?
From: "\241\271\324jE\032@d\200\252\bk\222\264" ;tag=3612846472-761912
Regards,
Nitin Kapoor
___
Sip-i
Dear All,
Can you please help me on one issue, where one of client is complaining
that they need RTP even port in SDP not the ODD. Which is Fax Call.
Although I checked the RFC 2327 & 4566 for SDP. In RFC 2327 its clearly
mentioned that we should use even port for RTP compliance, whereas in RFC
Dear All,
I have query regarding the PRACK.
I have the call scenario where my SBC send the INVITE to vendor including
100 rel and from vendor we received the rseq. Now I can see that my
customers sends 200 OK for PRACK. But after that continuously my vendor is
sending 183 w/SDP or 180 w/SDP and a
Hi Brett,
Thanks for your reply. However actually the problem i am facing is.
I have call flow as below.
UAC INVITE
w/SDP-> UAS
UAC <--183 w/SDP along with RSEQ-
UAS
UAC
--
Dear All,
I have query related to PRACK response time.
Can you please let me know what is the standard time to get 200 OK for the
PRACK from UAC or UAS.
For example :
UAC --> PRACK --> UAS
UAC <- What is standard time to reply 200 OK for this PRA
34 matches
Mail list logo
