[cisco-voip] Need SIP invite to route on TO field instead of URI

Mon Jul 2 17:51:31 EDT 2012

That's certainly an interesting problem.

You have an inbound SIP message, and selecting the inbound dial-peer isn't
really what you're concerned with. You're more concerned that the outbound
H.323 dial-peer selection is only going to look at the called number in the
SIP Request URI (which is the billing number).

It sounds like you need to do some work on the inbound SIP dial-peer to
manipulate that Request URI and stick the TO header inside of it. Then you
want to have this message processed by IOS  to find the right H.323
dial-peer based on your modification.

Another option is to change the header that IOS looks at when going from
SIP to H323 for pulling out the called number, but I have no idea how to do
that.

This example would copy the TO header into the Request-URI portion, but I
think you're right that it's really only meant for SIP to SIP. We'd pass
the modified SIP message out the far side, but I don't know if we'd make
the modification on the inbound leg and then change our next hop routing
based on this modification. I don't think it was intended for SIP to H.323.

https://supportforums.cisco.com/thread/2119596

How about converting the CUBE to be SIP-SIP? There may be other solutions
but I'm not brushed up enough on my IOS SIP modifications to come up with
something better! Anyone else have ideas?

-Jason

On Mon, Jul 2, 2012 at 10:12 AM, Jonathan Charles <jonvoip at gmail.com> wrote:

> These are also for Outbound.... I need to match on an INBOUND To field.
>
>
> On Mon, Jul 2, 2012 at 8:25 AM, Jason Burns <burns.jason at gmail.com> wrote:
>
>> IOS does have the ability to match on more than just the calling and
>> called numbers. Unfortunately the Cisco dial-peer matching document hasn't
>> been updated and I haven't found good official documentation, but look at
>> this link
>>
>> https://supportforums.cisco.com/docs/DOC-25219
>>
>> You can match on many parts of the SIP headers to route SIP calls. Even
>> more importantly, these header matches come before the usual calling and
>> called number type matches in terms of matching order. That doc should get
>> you started. It's for matching the incoming dial-peer, but the outbound
>> dial-peer configuration is similar.
>>
>> Actually - here is something that is a bit closer, but still not perfect.
>> At Cisco Live I found some great slides describing this. Let me see if I
>> can find those slides and come back with a better answer.
>>
>>
>> http://www.cisco.com/en/US/docs/ios/voice/ivr/configuration/guide/gt_url.html#wp1064328
>>
>> -Jason
>>
>>
>> On Mon, Jul 2, 2012 at 1:28 AM, Divin John <dijohn at cisco.com> wrote:
>>
>>> Try SIP Profiles.
>>>
>>> http://www.cisco.com/en/US/docs/ios-xml/ios/voice/cube_sip/configuration/15-2mt/voi-condl-header.html#GUID-980E7543-A7EC-41F4-800A-0ECAFAD8899F
>>>
>>> From: Jonathan Charles <jonvoip at gmail.com>
>>> Date: Monday 2 July 2012 10:32 AM
>>> To: <cisco-voip at puck.nether.net>
>>> Subject: [cisco-voip] Need SIP invite to route on TO field instead of
>>> URI
>>>
>>> I have a CUBE running 15.1(4)M4 that is SIP to the provider and H.323 to
>>> CUCM 8.6.2
>>>
>>> Inbound calls are all showing the billing number on the request URI:
>>>
>>>
>>> Jul  1 09:48:43.709 CDT: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>> Received:
>>> INVITE sip:1000 at 10.50.1.7:5060 SIP/2.0
>>> Via: SIP/2.0/UDP 1.1.1.1:5060
>>> ;branch=z9hG4bK-b09eefee3692d5c02b969912a045c958;rport
>>> From: "DOE, JOHN" <sip:16305551414 at call.message-alert.com
>>> >;tag=1813914414
>>> To: <sip:16305551212 at 1.1.1.1>
>>> Call-ID: 47e9ec2b at pbx
>>> CSeq: 22580 INVITE
>>> Max-Forwards: 70
>>> Contact: <sip:1000 at 1.1.1.1:5060;transport=udp>
>>> Supported: 100rel, replaces, norefersub
>>> Allow-Events: refer
>>> Allow: INVITE, ACK, CANCEL, BYE, REFER, PRACK, INFO, UPDATE
>>> Accept: application/sdp
>>> User-Agent: talkingplatforms/2.1.15.2503
>>> Alert-Info: <Bellcore-dr3>
>>> Content-Type: application/sdp
>>> Content-Length: 323
>>>
>>> v=0
>>> o=- 1303493202 1303493202 IN IP4 66.159.89.13
>>> s=-
>>> c=IN IP4 1.1.1.1
>>> t=0 0
>>> m=audio 57094 RTP/AVP 0 9 18 2 3 101
>>> a=rtpmap:0 pcmu/8000
>>> a=rtpmap:9 g722/8000
>>> a=rtpmap:18 g729/8000
>>> a=fmtp:18 annexb=no
>>> a=rtpmap:2 g726-32/8000
>>> a=rtpmap:3 gsm/8000
>>> a=rtpmap:101 telephone-event/8000
>>> a=fmtp:101 0-16
>>> a=sendrecv
>>>
>>>
>>>
>>>
>>> As you can see the INVITE is to sip:1000 at 10.50.1.7:5060, which is our
>>> billing code.
>>>
>>> The TO field has the actual DID to route to.
>>>
>>>
>>> Per the RFC, 3261, section 8.1.1.1:
>>>
>>> "The initial Request-URI of the message SHOULD be set to the value
>>> of the URI in the To field."
>>>
>>>
>>> This provider doesn't do that and says everyone but Cisco supports this,
>>> which goes back to my theory that SIP is not a protocol, but an idea of
>>> things you might want to do, but can really do whatever you want (hence the
>>> effect that every SIP provider seems to be doing their own thing)...
>>>
>>>
>>> Anyway, here is what I need to do:
>>>
>>> I need to have the call route on the TO field instead of the INVITE
>>> field.
>>>
>>> How?
>>>
>>>
>>>
>>> Jonathan
>>> _______________________________________________ cisco-voip mailing list
>>> cisco-voip at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20120702/f250d299/attachment.html>