Hi Nitin,
As per your call flow the second INVITE contains SDP and UAS is not
aware of if UAC has not send SDP in offer.
It sees the offer coming in INVITE. This scenario must be handled by
B2BUA which can send PRACK to Invite transaction it has created with
UAS. For the initial call flow with UA
Hi,
The Answer in 200 OK must be dupliacte of the one sent in 18X if there
is no Update done in between. @00 OK SDP must not be used for media
processing.
Regards
Sunil Verma
ESN: 877-5050
Ph: +919731245000
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[m
Hi Bemali,
Please check if the port on which SDP negotiation for video is blocked
by some firewall. Sometimes OS default settings blocks certain ports. Please
check using the respective OS commands.
ICMP doesn't seem to be related to either SIP or SDP, its something to
do with
Correction to my previous message: It is section "3.5.1 CRLF Keep-Alive
Technique" that I was referring to, not section 4.4.1.
_
Roman Shpount - www.telurix.com
On Thu, Jun 10, 2010 at 7:39 PM, Roman Shpount wrote:
> Hi All,
>
>
> I am trying to implement CRLF Keep Al
Hi All,
I am trying to implement CRLF Keep Alive mechanism from RFC 5626 and
cannot decipher the meaning of the following phrase (from section
4.4.1)
If a pong is not received within 10 seconds after sending a ping (or
immediately after processing any incoming message being received when
that 1
Hi Brett,
Actually the INVITE which is coming from source UA to SBC doesnt not have
100rel in Supported header, but yes on the second leg.. from SBC to remote
entity have the *100rel* in supported header.
*First leg(from Source to SBC): *
*Supported: timer,resource-priority,replaces
Supported: G
If INVITE indicated support for 100rel within Supported or Require, see RFC
3262 section 5.
> -Original Message-
> From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-
> implementors-boun...@lists.cs.columbia.edu] On Behalf Of Nitin Kapoor
> Sent: Thursday, June 10, 2010 1:54
Dear All,
I have a call flow like this.
UAC(SIP) -> Invite/without SDP --> B2BUA -Invite/with SDP
default port-> UAS(SIP)
Now as far as I know what RFC says that:
“The initial offer MUST be in either an INVITE or, if not there, in the
first reliable non-failure message f
Uttam,
On 06/10/2010 09:46 AM, Uttam Sarkar wrote:
> SDP in 18X and 200 OK must be same from the same endpoint (to-tag).
> If endpoint has sent SDP in 18X and it's confirmed by UAS ( using PRACK ),
> UAC does not need to send SDP in 200 OK ( it's optional to send SDP in 200
> OK in that case).
S
Alex,
SDP in 18X and 200 OK must be same from the same endpoint (to-tag).
If endpoint has sent SDP in 18X and it's confirmed by UAS ( using PRACK ), UAC
does not need to send SDP in 200 OK ( it's optional to send SDP in 200 OK in
that case).
-Original Message-
From: sip-implementors-bou
Hi all,
I'm implementing a SIP phone using RTC Client and Streamcoders RTP AV source
filter (only sourcing audio and video). I get the signalling part completely
OK, and the call gets connected after a successful SDP negotiation. Also RTP
AV source filter also gets connected successfully and I coul
Because 1xx responses are not reliable unless PRACK is used.
On Thu, Jun 10, 2010 at 6:35 PM, Alex Balashov
wrote:
> Greetings,
>
> If in a typical INVITE transaction to set up a session there can be
> only one SDP offer and one answer, and the first answer is final, then
> why the practice of se
Greetings,
If in a typical INVITE transaction to set up a session there can be
only one SDP offer and one answer, and the first answer is final, then
why the practice of sending 18x+SDP and then sending the answer again
in 200 OK?
Thanks,
--
Alex Balashov - Principal
Evariste Systems LLC
117
13 matches
Mail list logo
