I think "received" was introduced so that response reach the sip-node
that sent the request. It has nothing to do with NAT as 3261 never
considered and address this problem.
So, if the top most Via contains non-ip sent-by, the UAS is supposed
to replace it with the IP address from where it has rece
> > On Wed, Apr 9, 2008 at 7:05 AM, Andrea <[EMAIL PROTECTED]> wrote:
> > > Yu Marilyn-Q12239 wrote:
> > > > Look at your RTP stream in the trace. Asterisk is not only a SIP
> B2BUA,
> > > > it is a RTP B2B too. It doesn't need to let B know A's address
change
> to
> > > > forward RTP.
> > > >
> >
It is certainly legal to continue retransmitting the CANCEL even though
it will have no effect. A more interesting question is whether it is
legal to suppress retransmissions in this case. From a practical
perspective I see no problem with doing that if you wish.
Paul
[EMAIL PROTECTED]
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:sip-
> [EMAIL PROTECTED] On Behalf Of Iñaki Baz
> Castillo
>
> El Thursday 03 April 2008 17:38:17 Jim Kendrick escribió:
> > Have you found a solution for the AGL limit for incoming calls?
>
> AFAIK the only "real" solution (in SIP UD
From: praveen dandin <[EMAIL PROTECTED]>
Is it valid for UAC to retransmit CANCEL request even after getting
200 OK for INVITE (until UAC receives 200 OK for CANCEL or CANCEL
transaction times out)?
Yes, of course. It just has no effect. Among other reasons, the UAS
has to be prepar
Hi,
Consider the scenario as below:
UACUAS
| INVITE|
|-->|
| 180
Hi Nitin,
> UPDATE cannot be used here because it is the case to update "remote target"
> which in turn will change the dialog state.
> and UPDATE can only modify session related data not Dialog related.
> So Re-Invite shall be used here by A as soon as its CONTACT changes.
Quoting from section
This doesn't seem like an Asterisk issue to me. Like Treuz said, the
client must a RE-INVITE (Asterisk doesn't support incoming UPDATE
processing currently) to modify the remote target (Contact) for the
BYE from Asterisk to reach the new address of the client.
As far as how the RTP destination cha
Yu Marilyn-Q12239 wrote:
> Look at your RTP stream in the trace. Asterisk is not only a SIP B2BUA,
> it is a RTP B2B too. It doesn't need to let B know A's address change to
> forward RTP.
>
>
[EMAIL PROTECTED] wrote:
>From: Andrea <[EMAIL PROTECTED]>
>
>Yes i traced the whole session
