Hi,
I have written code that can do MTP1,MTP2,MTP3,ISUP, and I tested it with E1
line. What I need to do next is to interface with a OC-3 equipment with a
fabric optical link. Does anyone have any pointer on how to starting
decoding the OC-3 signal and demultiplex it to E1s?
Any pointer on how
> -Original Message-
> From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
> Sent: Friday, November 28, 2008 11:31 PM
>
> Actually, there is. Its 'Request-Disposition: no-fork' form RFC 3841. :-)
Oh right - wow forgot about that one. How could I forget caller-prefs? ;)
-hadriel
Hadriel Kaplan wrote:
>
>> -Original Message-
>> From: Alex Balashov [mailto:[EMAIL PROTECTED]
>> Sent: Friday, November 28, 2008 8:51 PM
>>
>> I should add here that yes, creating multiple early dialogs works around
>> that problem, but I would think it is implicit in the general formul
> -Original Message-
> From: Alex Balashov [mailto:[EMAIL PROTECTED]
> Sent: Friday, November 28, 2008 8:51 PM
>
> I should add here that yes, creating multiple early dialogs works around
> that problem, but I would think it is implicit in the general formula of
> UAC<->UAS interaction th
Alex Balashov wrote:
> Paul Kyzivat wrote:
>
>> Alex,
>>
>> If I understand you, you are arguing that either:
>> - proxies shouldn't fork at all, or
>> - proxies should violate 3261 by not forwarding
>> some provisional responses when forking.
>>
>> In the description, the proxy is acting exac
> -Original Message-
> From: Alex Balashov [mailto:[EMAIL PROTECTED]
> Sent: Friday, November 28, 2008 8:48 PM
>
> You're right. Is SDP in non-183 1xx messages particularly common?
In 180 Ringing it's not very common, but not rare either. I don't think I've
ever seen it another provis
Alex Balashov wrote:
> Alex Balashov wrote:
>
>>> The B2BUA is basically broken if it sends them all back with the same
>>> to-tag but unique SDP, IMO.
>> But isn't it just following the rule in 13.3.1.1 that all provisional
>> responses *sent by a UAS* must have the same dialog-identifying at
Alex Balashov wrote:
>> The B2BUA is basically broken if it sends them all back with the same
>> to-tag but unique SDP, IMO.
>
> But isn't it just following the rule in 13.3.1.1 that all provisional
> responses *sent by a UAS* must have the same dialog-identifying attributes?
I should add here
Hadriel Kaplan wrote:
>
>> -Original Message-
>> From: [EMAIL PROTECTED] [mailto:sip-
>> [EMAIL PROTECTED] On Behalf Of Alex Balashov
>> Sent: Friday, November 28, 2008 7:34 PM
>>
>> The problem is that 183+SDP is not an "ordinary" provisional response
>> because it has the potential to en
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:sip-
> [EMAIL PROTECTED] On Behalf Of Alex Balashov
> Sent: Friday, November 28, 2008 7:34 PM
>
> The problem is that 183+SDP is not an "ordinary" provisional response
> because it has the potential to enact media flow, not just provi
Paul Kyzivat wrote:
> Alex,
>
> If I understand you, you are arguing that either:
> - proxies shouldn't fork at all, or
> - proxies should violate 3261 by not forwarding
> some provisional responses when forking.
>
> In the description, the proxy is acting exactly as it should. And it has
> n
Alex,
If I understand you, you are arguing that either:
- proxies shouldn't fork at all, or
- proxies should violate 3261 by not forwarding
some provisional responses when forking.
In the description, the proxy is acting exactly as it should. And it has
no way of knowing its UAC is actually a
However, my reading of the early media RFC (3960)'s discussion of
forking is that it's generally just not considered a good idea to do
183+SDP with forking. Am I wrong?
Alex Balashov wrote:
>
> Iñaki,
>
> It would seem to me that it is incumbent upon the proxy to insulate the
> B2BUA from
Iñaki,
It would seem to me that it is incumbent upon the proxy to insulate the
B2BUA from the consequences of parallel forking by not creating such a
condition, since forking behaviour is a feature that is a defined and
specified as a characteristic of proxies rather than B2BUAs. The RFC
doe
Yes, I agree with you. This has been discussed before on one of the lists.
You can forget all the B2BUA issues and just view the B2BUA as a UAS
interacting with A, and ask if what it is doing is valid, without regard
to why it is doing it.
In addition to the reasons you have given, if the SDP i
Hi, I'm reporting a common error in some transparent B2BUA I'm testing. The
error is:
- The B2BUA receives a request from leg_A and generates a request in leg_B.
- leg_B arrives to a proxy that does parallel forking.
- The B2BUA receives various provisional responses (183) with different To_tag
El Viernes, 28 de Noviembre de 2008, Rockson Li (zhengyli) escribió:
> 13.2.1 Creating the Initial INVITE
Thanks !
--
Iñaki Baz Castillo
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/l
13.2.1 Creating the Initial INVITE
o If the initial offer is in an INVITE, the answer MUST be in a
reliable non-failure message from UAS back to UAC which is
correlated to that INVITE. For this specification, that is
only the final 2xx response to that INVITE. T
On Fri, Nov 28, 2008 at 3:31 PM, Iñaki Baz Castillo <[EMAIL PROTECTED]> wrote:
> Hi, I'm 100% sure that an UAC receiving two different SDP's during the same
> early-dialog (SDP_1 in 183 and SDP_2 in 200) should ignore/discard the second
> SDP_2.
There is not different SDP in an unreliable provisi
Hi, I'm 100% sure that an UAC receiving two different SDP's during the same
early-dialog (SDP_1 in 183 and SDP_2 in 200) should ignore/discard the second
SDP_2.
But could I know in which section of RFC 3261 (or other) is it specified? I
don't remember it now...
Thanks a lot.
--
Iñaki Baz Ca
Klaus,
Those are the main public documents I am aware of. I am the chair of
the VoIP Security Alliance (VOIPSA) Best Practices project which is
charged with developing these sort of guidelines but after an initial
start a while back, the project hasn't progressed. I am looking to re-
start
Hi Klaus,
> I am trying to find publications about SIP/VoIP security (risks,
> guidelines for software implementors, guidelines for service
> providers ...)
>
> Currently I found:
> NIST SP800-58
> draft-ietf-speermint-voipthreats-00
> and some thesis about VoIP security
>
> Are there other
Hi!
I am trying to find publications about SIP/VoIP security (risks,
guidelines for software implementors, guidelines for service providers ...)
Currently I found:
NIST SP800-58
draft-ietf-speermint-voipthreats-00
and some thesis about VoIP security
Are there other documents regarding SIP
Hi,
Section 5.2.2 and 5.2.3 of
Guidelines for using the Privacy mechanism for SIP
Draft-munakata-sip-privacy-guideline-02
says that
"A privacy service should modify the i, u, e, and p lines to delete
the user's identity information when user privacy is requested with
Privacy:session."
On Thu, Nov 27, 2008 at 6:24 PM, Iñaki Baz Castillo <[EMAIL PROTECTED]> wrote:
> Hi, I've read Session Timers RFC but it's a bit confusing for me. I've a basic
> doubt:
>
> alice proxy bob
>
> - alice calls bob.
> - proxy doesn't implement SessionTimers (in the way a proxy could impleme
This actually is a very basic and significant terminology based on which some
RFCs are defined unfortunately.
Sec 7 of RFC3388 has clearly indicated the identifier of RTP session as IP+
(RTP + RTCP port)
This definition assumes that a single audio (or video) stream maps
into an RTP sess
28 nov 2008 kl. 10.37 skrev Iñaki Baz Castillo:
> El Viernes, 28 de Noviembre de 2008, Rockson Li (zhengyli) escribió:
>> why there're only three RTP sessions, I think it should be six?
>> since "each participant receiving from the other two on separate port
>> pairs"
>> which means each paritici
El Viernes, 28 de Noviembre de 2008, Rockson Li (zhengyli) escribió:
> why there're only three RTP sessions, I think it should be six?
> since "each participant receiving from the other two on separate port
> pairs"
> which means each pariticipant should listen on two separate port paris
> for inco
28 matches
Mail list logo
