date:20181008

Re: [cisco-voip] Jabber region restriction issue

2018-10-08 Thread Carlos G Mendioroz via cisco-voip

Indeed, an MTP was forced by the SIP trunk config.
I'll have to rethink my MTP strategy, because having had so many issues
with NOT having an MTP, I'm used to insert MTPs by default on SIP trunks.

Still not comfortable though, CUCM knows it's going to a dead end and
waits untill progress to "bail out". But I can understand why now (there
could have been xcodes to make the job, there are none).

Thanks!!!

Anthony Holloway @ 08/10/2018 01:16 -0300 dixit:
> Bernhard, Good job proposing an MTP is being invoked, and I would say
> the same.  There's a number of places/reasons an MTP could be inserted,
> how would you systematically check this?  I.e., What's your approach?
> 
> Also, we don't have to assume .2 is a CUCM node.  Look at the SIP Via:
> header.  The call flow was was described as: Jabber > CUCM > CUBE > SP,
> and the SIP request is label as being "CUBE received."
> 
> Not too mention the handful of other lines in that message which all
> point to .2 being a CUCM node. (SDP o line, SIP User-Agent header, etc.)
> *
> *
> 
> 
> On Sun, Oct 7, 2018 at 10:22 PM Bernhard Albler
> mailto:bernhard.alb...@gmail.com>> wrote:
> 
> looking at your invite it looks like an MTP is being invoked (
> assuming .2 is the address of a cucm node)
> Thats the reason g711 is being used
> now the question is if the MTP was inserted via config or because of
> some ( e.g. dtmf) other reason and if it is safe to remove it
> therefore...
> 
> On Mon 8. Oct 2018 at 00:21, Carlos G Mendioroz via cisco-voip
> mailto:cisco-voip@puck.nether.net>> wrote:
> 
> Hi,
> kind of rusty (me, long time since engaging in troubleshooting
> of Voip)
> but I encountered something weird (again, may be me).
> 
> Jabber Android (12.1) registered to CUCM (10.5) with region set
> with 16K
> audio limit.
> 
> Call comes from Jabber through CUCM to CUBE to SP, but signalled
> as G711
> and after session progress, it gets cancelled.
> 
> Shouldn't CUCM signal the call with G.729 in the first place ?
> 
> CUBE received:
> INVITE sip:947930020@10.0.100.1:5060
>  SIP/2.0
> Via: SIP/2.0/TCP 10.0.100.2:5060;branch=z9hG4bK235a8e855ad
> From:
>  
> >;tag=36658~4fdda745-cceb-4407-a170-1420de65d7d7-22052972
> To: mailto:sip%3A947930020@10.0.100.1>>
> Date: Sun, 07 Oct 2018 20:45:59 GMT
> Call-ID: fd98a300-bba17087-1b99-264000a@10.0.100.2
> 
> Supported: timer,resource-priority,replaces
> Min-SE:  1800
> User-Agent: Cisco-CUCM10.5
> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE,
> REFER,
> SUBSCRIBE, NOTIFY
> CSeq: 101 INVITE
> Expires: 180
> Allow-Events: presence, kpml
> Supported: X-cisco-srtp-fallback,X-cisco-original-called
> Cisco-Guid: 4254638848-065536-000690-0040108042
> Session-Expires:  1800
> P-Asserted-Identity:  >
> Remote-Party-ID:  >;party=calling;screen=yes;privacy=off
> Contact:
>  
> ;transport=tcp>;+u.sip!devicename.ccm.cisco.com
> ="BOTTRON"
> Max-Forwards: 13
> Content-Type: application/sdp
> Content-Length: 197
> 
> v=0
> o=CiscoSystemsCCM-SIP 36658 1 IN IP4 10.0.100.2
> s=SIP Call
> c=IN IP4 10.0.100.2
> t=0 0
> m=audio 26804 RTP/AVP 0 101
> a=rtpmap:0 PCMU/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-15
> 
> 
> TIA,
> -- 
> Carlos G Mendioroz   >  LW7 EQI  Argentina
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net 
> https://puck.nether.net/mailman/listinfo/cisco-voip
> 
> -- 
> Bernhard Albler, +4369917207384
> --
> "Was Nachwelt! Wie komm' ich dazu was für die Nachwelt zu tun? Was
> hat denn die Nachwelt für mich getan?"
> --Carl Friedrich Zelter
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net 
> https://puck.nether.net/mailman/listinfo/cisco-voip
> 

-- 
Carlos G MendiorozLW7 EQI  Argentina
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Jabber region restriction issue

2018-10-08 Thread Anthony Holloway

Carlos,

In my opinion, MTPs should not be used to fix issues, if non-MTP inducing
alternative fixes exist.  Or to say that another way: MTPs are a last
resort.  I do use them, sometimes, so don't get me wrong.  I'm not saying
they're bad and avoid them.

E.g., If your CUBE is set for rtp-nte DTMF relay only, on your CUCM facing
dial-peers, then MTPs will be invoked for calls going to, say, UCCX.  You
could invoke an MTP to fix those calls to UCCX, or you could just add an
Out of Band DTMF relay option on your dial-peers.



On Mon, Oct 8, 2018 at 5:25 AM Carlos G Mendioroz  wrote:

> Indeed, an MTP was forced by the SIP trunk config.
> I'll have to rethink my MTP strategy, because having had so many issues
> with NOT having an MTP, I'm used to insert MTPs by default on SIP trunks.
>
> Still not comfortable though, CUCM knows it's going to a dead end and
> waits untill progress to "bail out". But I can understand why now (there
> could have been xcodes to make the job, there are none).
>
> Thanks!!!
>
> Anthony Holloway @ 08/10/2018 01:16 -0300 dixit:
> > Bernhard, Good job proposing an MTP is being invoked, and I would say
> > the same.  There's a number of places/reasons an MTP could be inserted,
> > how would you systematically check this?  I.e., What's your approach?
> >
> > Also, we don't have to assume .2 is a CUCM node.  Look at the SIP Via:
> > header.  The call flow was was described as: Jabber > CUCM > CUBE > SP,
> > and the SIP request is label as being "CUBE received."
> >
> > Not too mention the handful of other lines in that message which all
> > point to .2 being a CUCM node. (SDP o line, SIP User-Agent header, etc.)
> > *
> > *
> >
> >
> > On Sun, Oct 7, 2018 at 10:22 PM Bernhard Albler
> > mailto:bernhard.alb...@gmail.com>> wrote:
> >
> > looking at your invite it looks like an MTP is being invoked (
> > assuming .2 is the address of a cucm node)
> > Thats the reason g711 is being used
> > now the question is if the MTP was inserted via config or because of
> > some ( e.g. dtmf) other reason and if it is safe to remove it
> > therefore...
> >
> > On Mon 8. Oct 2018 at 00:21, Carlos G Mendioroz via cisco-voip
> > mailto:cisco-voip@puck.nether.net>>
> wrote:
> >
> > Hi,
> > kind of rusty (me, long time since engaging in troubleshooting
> > of Voip)
> > but I encountered something weird (again, may be me).
> >
> > Jabber Android (12.1) registered to CUCM (10.5) with region set
> > with 16K
> > audio limit.
> >
> > Call comes from Jabber through CUCM to CUBE to SP, but signalled
> > as G711
> > and after session progress, it gets cancelled.
> >
> > Shouldn't CUCM signal the call with G.729 in the first place ?
> >
> > CUBE received:
> > INVITE sip:947930020@10.0.100.1:5060
> >  SIP/2.0
> > Via: SIP/2.0/TCP 10.0.100.2:5060;branch=z9hG4bK235a8e855ad
> > From:
> >  >  >>;tag=36658~4fdda745-cceb-4407-a170-1420de65d7d7-22052972
> > To: mailto:sip%3A947930020@10.0.100.1
> >>
> > Date: Sun, 07 Oct 2018 20:45:59 GMT
> > Call-ID: fd98a300-bba17087-1b99-264000a@10.0.100.2
> > 
> > Supported: timer,resource-priority,replaces
> > Min-SE:  1800
> > User-Agent: Cisco-CUCM10.5
> > Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE,
> > REFER,
> > SUBSCRIBE, NOTIFY
> > CSeq: 101 INVITE
> > Expires: 180
> > Allow-Events: presence, kpml
> > Supported: X-cisco-srtp-fallback,X-cisco-original-called
> > Cisco-Guid: 4254638848-065536-000690-0040108042
> > Session-Expires:  1800
> > P-Asserted-Identity:  > >
> > Remote-Party-ID:  >  >>;party=calling;screen=yes;privacy=off
> > Contact:
> >  > ;transport=tcp>;+u.sip!
> devicename.ccm.cisco.com
> > ="BOTTRON"
> > Max-Forwards: 13
> > Content-Type: application/sdp
> > Content-Length: 197
> >
> > v=0
> > o=CiscoSystemsCCM-SIP 36658 1 IN IP4 10.0.100.2
> > s=SIP Call
> > c=IN IP4 10.0.100.2
> > t=0 0
> > m=audio 26804 RTP/AVP 0 101
> > a=rtpmap:0 PCMU/8000
> > a=rtpmap:101 telephone-event/8000
> > a=fmtp:101 0-15
> >
> >
> > TIA,
> > --
> > Carlos G Mendioroz   > >  LW7 EQI  Argentina
> > ___
> > cisco-voip mailing list
> > cisco-voip@puck.nether.net 
> >

Re: [cisco-voip] Jabber region restriction issue

2018-10-08 Thread Carlos G Mendioroz via cisco-voip

Grr,
now that MTP is not forced, calls from CUCM phones to some dialpeers
(phones) on the CUBE fail :(

The only weirdness seems to be:

v=0
o=CiscoSystemsSIP-GW-UserAgent 2983 2791 IN IP4 10.0.100.1
s=SIP Call
c=IN IP4 10.0.100.1
t=0 0
m=audio 18746 RTP/AVP 9 116 0 8 18 101
c=IN IP4 10.0.100.1
a=rtpmap:9 G722/8000
a=fmtp:9 bitrate=64
a=rtpmap:116 iLBC/8000
a=fmtp:116 mode=20
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16

versus:

v=0
o=CiscoSystemsCCM-SIP 38001 1 IN IP4 10.0.100.2
s=SIP Call
c=IN IP4 10.0.100.5
b=TIAS:64000
b=AS:64
t=0 0
m=audio 49328 RTP/AVP 9 101
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtcp:49329 IN IP4 10.0.100.5

(note 101 0-16 and 0-15 missmatch).

The CUBE is tearing down with:

Reason: Q.850;cause=172



Carlos G Mendioroz via cisco-voip @ 08/10/2018 07:25 -0300 dixit:
> Indeed, an MTP was forced by the SIP trunk config.
> I'll have to rethink my MTP strategy, because having had so many issues
> with NOT having an MTP, I'm used to insert MTPs by default on SIP trunks.
> 
> Still not comfortable though, CUCM knows it's going to a dead end and
> waits untill progress to "bail out". But I can understand why now (there
> could have been xcodes to make the job, there are none).
> 
> Thanks!!!
> 
> Anthony Holloway @ 08/10/2018 01:16 -0300 dixit:
>> Bernhard, Good job proposing an MTP is being invoked, and I would say
>> the same.  There's a number of places/reasons an MTP could be inserted,
>> how would you systematically check this?  I.e., What's your approach?
>>
>> Also, we don't have to assume .2 is a CUCM node.  Look at the SIP Via:
>> header.  The call flow was was described as: Jabber > CUCM > CUBE > SP,
>> and the SIP request is label as being "CUBE received."
>>
>> Not too mention the handful of other lines in that message which all
>> point to .2 being a CUCM node. (SDP o line, SIP User-Agent header, etc.)
>> *
>> *
>>
>>
>> On Sun, Oct 7, 2018 at 10:22 PM Bernhard Albler
>> mailto:bernhard.alb...@gmail.com>> wrote:
>>
>> looking at your invite it looks like an MTP is being invoked (
>> assuming .2 is the address of a cucm node)
>> Thats the reason g711 is being used
>> now the question is if the MTP was inserted via config or because of
>> some ( e.g. dtmf) other reason and if it is safe to remove it
>> therefore...
>>
>> On Mon 8. Oct 2018 at 00:21, Carlos G Mendioroz via cisco-voip
>> mailto:cisco-voip@puck.nether.net>> wrote:
>>
>> Hi,
>> kind of rusty (me, long time since engaging in troubleshooting
>> of Voip)
>> but I encountered something weird (again, may be me).
>>
>> Jabber Android (12.1) registered to CUCM (10.5) with region set
>> with 16K
>> audio limit.
>>
>> Call comes from Jabber through CUCM to CUBE to SP, but signalled
>> as G711
>> and after session progress, it gets cancelled.
>>
>> Shouldn't CUCM signal the call with G.729 in the first place ?
>>
>> CUBE received:
>> INVITE sip:947930020@10.0.100.1:5060
>>  SIP/2.0
>> Via: SIP/2.0/TCP 10.0.100.2:5060;branch=z9hG4bK235a8e855ad
>> From:
>> > 
>> >;tag=36658~4fdda745-cceb-4407-a170-1420de65d7d7-22052972
>> To: mailto:sip%3A947930020@10.0.100.1>>
>> Date: Sun, 07 Oct 2018 20:45:59 GMT
>> Call-ID: fd98a300-bba17087-1b99-264000a@10.0.100.2
>> 
>> Supported: timer,resource-priority,replaces
>> Min-SE:  1800
>> User-Agent: Cisco-CUCM10.5
>> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE,
>> REFER,
>> SUBSCRIBE, NOTIFY
>> CSeq: 101 INVITE
>> Expires: 180
>> Allow-Events: presence, kpml
>> Supported: X-cisco-srtp-fallback,X-cisco-original-called
>> Cisco-Guid: 4254638848-065536-000690-0040108042
>> Session-Expires:  1800
>> P-Asserted-Identity: > >
>> Remote-Party-ID: > >;party=calling;screen=yes;privacy=off
>> Contact:
>> > 
>> ;transport=tcp>;+u.sip!devicename.ccm.cisco.com
>> ="BOTTRON"
>> Max-Forwards: 13
>> Content-Type: application/sdp
>> Content-Length: 197
>>
>> v=0
>> o=CiscoSystemsCCM-SIP 36658 1 IN IP4 10.0.100.2
>> s=SIP Call
>> c=IN IP4 10.0.100.2
>> t=0 0
>> m=audio 26804 RTP/AVP 0 101
>> a=rtpmap:0 PCMU/8000
>> a=rtpmap:101 telephone-event/8000
>> a=fmtp:101 0-15
>>
>>
>> TIA,
>> -- 
>> Carlos G Mendioroz  >

Re: [cisco-voip] Jabber region restriction issue

2018-10-08 Thread Carlos G Mendioroz via cisco-voip

FTR, this proved to be tough on me.
And I thought I knew something about it :)

Ended up removing a force rtp-nte that was there, and adding sip-kpml as
an alternative on the CUBE (performing as a CME in this case too).

And changed the sip profile on the CUCM to do Early offer (best effort).

HTH someone in the future.
-Carlos

Kent Roberts @ 08/10/2018 13:17 -0300 dixit:
> You might update your dial-peers to use G729 and G711 only. Not all 
> carriers support G722.   Or put it as 3rd of 4th option.Also might try 
> early offer on the cube.
> 
> 
> 
> 
>> On Oct 8, 2018, at 10:10 AM, Carlos G Mendioroz via cisco-voip 
>>  wrote:
>>
>> Grr,
>> now that MTP is not forced, calls from CUCM phones to some dialpeers
>> (phones) on the CUBE fail :(
>>
>> The only weirdness seems to be:
>>
>> v=0
>> o=CiscoSystemsSIP-GW-UserAgent 2983 2791 IN IP4 10.0.100.1
>> s=SIP Call
>> c=IN IP4 10.0.100.1
>> t=0 0
>> m=audio 18746 RTP/AVP 9 116 0 8 18 101
>> c=IN IP4 10.0.100.1
>> a=rtpmap:9 G722/8000
>> a=fmtp:9 bitrate=64
>> a=rtpmap:116 iLBC/8000
>> a=fmtp:116 mode=20
>> a=rtpmap:0 PCMU/8000
>> a=rtpmap:8 PCMA/8000
>> a=rtpmap:18 G729/8000
>> a=fmtp:18 annexb=no
>> a=rtpmap:101 telephone-event/8000
>> a=fmtp:101 0-16
>>
>> versus:
>>
>> v=0
>> o=CiscoSystemsCCM-SIP 38001 1 IN IP4 10.0.100.2
>> s=SIP Call
>> c=IN IP4 10.0.100.5
>> b=TIAS:64000
>> b=AS:64
>> t=0 0
>> m=audio 49328 RTP/AVP 9 101
>> a=rtpmap:9 G722/8000
>> a=rtpmap:101 telephone-event/8000
>> a=fmtp:101 0-15
>> a=rtcp:49329 IN IP4 10.0.100.5
>>
>> (note 101 0-16 and 0-15 missmatch).
>>
>> The CUBE is tearing down with:
>>
>> Reason: Q.850;cause=172
>>
>>
>>
>> Carlos G Mendioroz via cisco-voip @ 08/10/2018 07:25 -0300 dixit:
>>> Indeed, an MTP was forced by the SIP trunk config.
>>> I'll have to rethink my MTP strategy, because having had so many issues
>>> with NOT having an MTP, I'm used to insert MTPs by default on SIP trunks.
>>>
>>> Still not comfortable though, CUCM knows it's going to a dead end and
>>> waits untill progress to "bail out". But I can understand why now (there
>>> could have been xcodes to make the job, there are none).
>>>
>>> Thanks!!!
>>>
>>> Anthony Holloway @ 08/10/2018 01:16 -0300 dixit:
 Bernhard, Good job proposing an MTP is being invoked, and I would say
 the same.  There's a number of places/reasons an MTP could be inserted,
 how would you systematically check this?  I.e., What's your approach?

 Also, we don't have to assume .2 is a CUCM node.  Look at the SIP Via:
 header.  The call flow was was described as: Jabber > CUCM > CUBE > SP,
 and the SIP request is label as being "CUBE received."

 Not too mention the handful of other lines in that message which all
 point to .2 being a CUCM node. (SDP o line, SIP User-Agent header, etc.)
 *
 *

 On Sun, Oct 7, 2018 at 10:22 PM Bernhard Albler
 mailto:bernhard.alb...@gmail.com>> wrote:

looking at your invite it looks like an MTP is being invoked (
assuming .2 is the address of a cucm node)
Thats the reason g711 is being used
now the question is if the MTP was inserted via config or because of
some ( e.g. dtmf) other reason and if it is safe to remove it
therefore...

On Mon 8. Oct 2018 at 00:21, Carlos G Mendioroz via cisco-voip
mailto:cisco-voip@puck.nether.net>> wrote:

Hi,
kind of rusty (me, long time since engaging in troubleshooting
of Voip)
but I encountered something weird (again, may be me).

Jabber Android (12.1) registered to CUCM (10.5) with region set
with 16K
audio limit.

Call comes from Jabber through CUCM to CUBE to SP, but signalled
as G711
and after session progress, it gets cancelled.

Shouldn't CUCM signal the call with G.729 in the first place ?

CUBE received:
INVITE sip:947930020@10.0.100.1:5060
 SIP/2.0
Via: SIP/2.0/TCP 10.0.100.2:5060;branch=z9hG4bK235a8e855ad
From:
>>>
 >;tag=36658~4fdda745-cceb-4407-a170-1420de65d7d7-22052972
To: mailto:sip%3A947930020@10.0.100.1>>
Date: Sun, 07 Oct 2018 20:45:59 GMT
Call-ID: fd98a300-bba17087-1b99-264000a@10.0.100.2

Supported: timer,resource-priority,replaces
Min-SE:  1800
User-Agent: Cisco-CUCM10.5
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE,
REFER,
SUBSCRIBE, NOTIFY
CSeq: 101 INVITE
Expires: 180
Allow-Events: presence, kpml
Supported: X-cisco-srtp-fallback,X-cisco-original-called
Cisco-Guid:

Re: [cisco-voip] Jabber region restriction issue

2018-10-08 Thread Kent Roberts

You might update your dial-peers to use G729 and G711 only. Not all 
carriers support G722.   Or put it as 3rd of 4th option.Also might try 
early offer on the cube.




> On Oct 8, 2018, at 10:10 AM, Carlos G Mendioroz via cisco-voip 
>  wrote:
> 
> Grr,
> now that MTP is not forced, calls from CUCM phones to some dialpeers
> (phones) on the CUBE fail :(
> 
> The only weirdness seems to be:
> 
> v=0
> o=CiscoSystemsSIP-GW-UserAgent 2983 2791 IN IP4 10.0.100.1
> s=SIP Call
> c=IN IP4 10.0.100.1
> t=0 0
> m=audio 18746 RTP/AVP 9 116 0 8 18 101
> c=IN IP4 10.0.100.1
> a=rtpmap:9 G722/8000
> a=fmtp:9 bitrate=64
> a=rtpmap:116 iLBC/8000
> a=fmtp:116 mode=20
> a=rtpmap:0 PCMU/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:18 G729/8000
> a=fmtp:18 annexb=no
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> 
> versus:
> 
> v=0
> o=CiscoSystemsCCM-SIP 38001 1 IN IP4 10.0.100.2
> s=SIP Call
> c=IN IP4 10.0.100.5
> b=TIAS:64000
> b=AS:64
> t=0 0
> m=audio 49328 RTP/AVP 9 101
> a=rtpmap:9 G722/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-15
> a=rtcp:49329 IN IP4 10.0.100.5
> 
> (note 101 0-16 and 0-15 missmatch).
> 
> The CUBE is tearing down with:
> 
> Reason: Q.850;cause=172
> 
> 
> 
> Carlos G Mendioroz via cisco-voip @ 08/10/2018 07:25 -0300 dixit:
>> Indeed, an MTP was forced by the SIP trunk config.
>> I'll have to rethink my MTP strategy, because having had so many issues
>> with NOT having an MTP, I'm used to insert MTPs by default on SIP trunks.
>> 
>> Still not comfortable though, CUCM knows it's going to a dead end and
>> waits untill progress to "bail out". But I can understand why now (there
>> could have been xcodes to make the job, there are none).
>> 
>> Thanks!!!
>> 
>> Anthony Holloway @ 08/10/2018 01:16 -0300 dixit:
>>> Bernhard, Good job proposing an MTP is being invoked, and I would say
>>> the same.  There's a number of places/reasons an MTP could be inserted,
>>> how would you systematically check this?  I.e., What's your approach?
>>> 
>>> Also, we don't have to assume .2 is a CUCM node.  Look at the SIP Via:
>>> header.  The call flow was was described as: Jabber > CUCM > CUBE > SP,
>>> and the SIP request is label as being "CUBE received."
>>> 
>>> Not too mention the handful of other lines in that message which all
>>> point to .2 being a CUCM node. (SDP o line, SIP User-Agent header, etc.)
>>> *
>>> *
>>> 
>>> 
>>> On Sun, Oct 7, 2018 at 10:22 PM Bernhard Albler
>>> mailto:bernhard.alb...@gmail.com>> wrote:
>>> 
>>>looking at your invite it looks like an MTP is being invoked (
>>>assuming .2 is the address of a cucm node)
>>>Thats the reason g711 is being used
>>>now the question is if the MTP was inserted via config or because of
>>>some ( e.g. dtmf) other reason and if it is safe to remove it
>>>therefore...
>>> 
>>>On Mon 8. Oct 2018 at 00:21, Carlos G Mendioroz via cisco-voip
>>>mailto:cisco-voip@puck.nether.net>> wrote:
>>> 
>>>Hi,
>>>kind of rusty (me, long time since engaging in troubleshooting
>>>of Voip)
>>>but I encountered something weird (again, may be me).
>>> 
>>>Jabber Android (12.1) registered to CUCM (10.5) with region set
>>>with 16K
>>>audio limit.
>>> 
>>>Call comes from Jabber through CUCM to CUBE to SP, but signalled
>>>as G711
>>>and after session progress, it gets cancelled.
>>> 
>>>Shouldn't CUCM signal the call with G.729 in the first place ?
>>> 
>>>CUBE received:
>>>INVITE sip:947930020@10.0.100.1:5060
>>> SIP/2.0
>>>Via: SIP/2.0/TCP 10.0.100.2:5060;branch=z9hG4bK235a8e855ad
>>>From:
>>>>>
>>> >;tag=36658~4fdda745-cceb-4407-a170-1420de65d7d7-22052972
>>>To: mailto:sip%3A947930020@10.0.100.1>>
>>>Date: Sun, 07 Oct 2018 20:45:59 GMT
>>>Call-ID: fd98a300-bba17087-1b99-264000a@10.0.100.2
>>>
>>>Supported: timer,resource-priority,replaces
>>>Min-SE:  1800
>>>User-Agent: Cisco-CUCM10.5
>>>Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE,
>>>REFER,
>>>SUBSCRIBE, NOTIFY
>>>CSeq: 101 INVITE
>>>Expires: 180
>>>Allow-Events: presence, kpml
>>>Supported: X-cisco-srtp-fallback,X-cisco-original-called
>>>Cisco-Guid: 4254638848-065536-000690-0040108042
>>>Session-Expires:  1800
>>>P-Asserted-Identity: >>>
>>>Remote-Party-ID: >>>;party=calling;screen=yes;privacy=off
>>>Contact:
>>>>>
>>> ;transport=tcp>;+u.sip!devicename.ccm.cisco.com
>>>="BOTTRON"
>>>Max-Forwards: 13
>>>Content-Type: application/sdp
>>>

Re: [cisco-voip] Jabber region restriction issue

Re: [cisco-voip] Jabber region restriction issue

Re: [cisco-voip] Jabber region restriction issue

Re: [cisco-voip] Jabber region restriction issue

Re: [cisco-voip] Jabber region restriction issue

5 matches

Site Navigation

Mail list logo

Footer information