Hi,
Thats question i asked several times here, to be honest no 100% workable
solution.
So after drinking many beers the idea flashed to brain and
implementation seems to work nice so far.
Approach below works even if both UAs behind (different) NAT, as long as
UA keep connection/flow alive ...
El Jueves, 14 de Agosto de 2008, Nenad Milidrag escribió:
> Hi Arif,
>
> You can use rport to solve that problem. When phone with private ip
> gets its public ip re-register with your public ip/port.
Well, this is a phone solution (is it really used?) but it needs the phone
registering against t
Hi Arif,
You can use rport to solve that problem. When phone with private ip
gets its public ip re-register with your public ip/port.
Regards,
Nenad
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Arif
Sent: Thursday, August 14, 2008 3:31 PM
To: sip-imp
From: Miles Scruggs <[EMAIL PROTECTED]>
In this instance there is a PSTN gateway which has provided us with
multiple IPs to send calls to. If their network is congested for that
call then they spit back a 503. We then in turn try to send the call
down each on of their IPs an
El Jueves, 14 de Agosto de 2008, Miles Scruggs escribió:
> Hi,
>
> What is the correct response for a PSTN gateway to reply with when
> their entire network is congested. aka "Please don't try this or any
> other server on our network for this call, but feel free to use
> another gateway(that isn'
El Jueves, 14 de Agosto de 2008, Arif escribió:
> However IF UAS wants to end the session with BYE, it will send this request
> to Proxy (coz proxy had record-routed), but how shall proxy route this
> request back to UAC (which is behind NAT), coz the contact address which
> UAC had sent in initial
Hi,
What is the correct response for a PSTN gateway to reply with when
their entire network is congested. aka "Please don't try this or any
other server on our network for this call, but feel free to use
another gateway(that isn't ours) as we don't control the end point and
your call sti
Hi!!
I am kind of lost in a scenario..where..
UAC (behind NAT) initiates a session with a UAS (Not behind NAT) through Proxy
(Statefull)..
Now invite goes to Proxy and then routed to UAS.. and response is also relayed
back to UAC as per rfc 3261 and 3581..
The UAC does not use any STUN etc.
Ho
El Thursday 14 August 2008 10:16:14 Rockson Li (zhengyli) escribió:
> > [RL] since INVITE server transaction would be terminated on delivery
> > of 2xx, so I think CANCEL cannot match any to-be-cancelled
> > transaction, so 481 would be sent.
>
> But what about if the final response was [3456]XX ?
El Thursday 14 August 2008 07:48:58 Somesh S. Shanbhag escribió:
> "to-Tag" is TU specific and must be added by the concerned TU.
>
> For Example, if server is behaving as Proxy, the ProxyCore would add
> "to-Tag" and pass the response to the transaction.
>
> Since, adding "to-Tag" is common across
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of I?aki Baz
Castillo
Sent: Thursday, August 14, 2008 4:08 PM
To: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] About CANCEL proccesing in a UAS
El Thursday 14 August 2008 05:44:42 R
El Thursday 14 August 2008 05:44:42 Rockson Li (zhengyli) escribió:
> > 2) - UAS receives a CANCEL for an INVITE transaction for which UAS has
> > already sent a final response. In this case RFC3261 says:
> >
> >"the CANCEL
> >request has no effect on the processing of the original request
El Thursday 14 August 2008 05:22:40 Rockson Li (zhengyli) escribió:
> I think you're mostly correct.
>
> Request(CANCEL is not special) retransmission is first checked in server
> transaction layer based on server transaction match( RFC3261 sec 17.2.3.)
And also I realized that the TransactonLayer
13 matches
Mail list logo
