한국어

소프트스위치

온누리070 플레이스토어 다운로드
    acrobits softphone
     온누리 070 카카오 프러스 친구추가온누리 070 카카오 프러스 친구추가친추
     카카오톡 채팅 상담 카카오톡 채팅 상담카톡
    
     라인상담
     라인으로 공유

     페북공유

   ◎위챗 : speedseoul


  
     PAYPAL
     
     PRICE
     

pixel.gif

    before pay call 0088 from app



https://blog.opensips.org/2017/03/10/advanced-sip-scenarios-with-event-based-routing/



route[route_to_user] {

    # prepare transaction for branch injection; it is mandatory
    # to create the transaction before the subscription, otherwise
    # the EBR module will not pass the transaction ID into the
    # notification route
    t_newtran();

    # keep the transaction alive (even if all branches will
    # terminate) until the FR INVITE timer hits (we want to wait
    # for new possible contacts being registered)
    t_wait_for_new_branches();

    # subscribe to new contact registration event, but for our callee only
    $avp(filter) = "aor="+$rU;
    notify_on_event("E_UL_CONTACT_INSERT","$avp(filter)", "fork_call", "20");

    # fetch already registered contacts and relay if any
    if (lookup("location"))
        route(relay);
    # if there were no contacts available (so no branches created so far),
    # the created transaction will still be waiting for new branches due 
    # to the usage of the t_wait_for_new_branches() function

    exit;
}

route[fork_call]  {
    xlog("user $avp(aor) registered the a new contact $avp(uri), "
        "injecting it in transaction\n");
    # take the contact described by the E_UL_CONTACT_INSERT
    # event and inject it as a new branch into the original transaction
    t_inject_branches("event");
}

1.4.15.  t_inject_branches(source[,flags])

The function adds new SIP branches (destinations) to an existing transaction and fires them (sends them out). The transaction may already have ongoing branches (like in ringing state), which will not be affected by the injection of the new branches. Also it is possible for the transaction not to have any ongoing branches at the moment of the injection (still, the transaction must wait for new branches, even if all existing ones are completed - see the t_wait_for_new_branches function for this).

The main usage scenario for this function (and also what makes it different from t_relay is the ability to add new branches to an ongoing transaction from script routes not related to the transaction ( like timer route, event route, notification route, and other). In such routes, other functions/module used before the injection will point to the transaction to be affected by this injection - see the event_routing module.


이 함수는 새 SIP 분기 (대상)를 기존 트랜잭션에 추가하고 해당 트랜잭션을 실행 (전송)합니다. 트랜잭션에는 이미 새 브랜치의 주입에 영향을받지 않는 링잉 상태와 같은 진행중인 브랜치가있을 수 있습니다. 또한 트랜잭션이 주입 순간에 진행중인 분기를 가지지 않을 수도 있습니다 (여전히 기존의 트랜잭션이 완료된 경우에도 트랜잭션은 새 분기를 기다려야합니다 - 이에 대한 t_wait_for_new_branches 함수 참조).

이 기능의 주요 사용 시나리오 (또한 t_relay와 다른 점은 트랜잭션과 관련없는 스크립트 경로 (예 : 타이머 경로, 이벤트 경로, 알림 경로 및 기타)에서 진행중인 트랜잭션에 새 분기를 추가하는 기능입니다. 이러한 경로에서 주입 전에 사용 된 다른 함수 / 모듈은이 주입에 의해 영향을받는 트랜잭션을 가리 킵니다. event_routing 모듈을 참조하십시오.


매개 변수 :

source - 새로운 브랜치에 대한 설명을 어디에 주입 할 것인가? 그것은 될 수 있습니다

event - 브랜치는 이벤트 알림 경로에 노출 된 이벤트 속성에서 가져옵니다 (event_routing 모듈 참조).

msg - SIP 메시지의 RURI와 추가 분기 (append_branch () 함수 또는 유사하게 생성 된)에서 분기됩니다.

flags - (선택 사항) 주입 프로세스와 관련된 몇 가지 추가 플래그 :

취소 - 새 분기를 주입하기 전에 트랜잭션에서 진행중인 기존 분기를 모두 취소합니다.


Parameters:

  • source - where to take the description for the new branches to be injected. It can be

    • event - the branch will be taken from the event attributes exposed in an event notification route (see event_routing module).
    • msg - the branches will be taken from the RURI of the SIP message and from the additional branches (created by append_branch() function or similar).

  • flags - (optional) some additional flags related to the injection process:

    • cancel - cancel all the ongoing existing branches from the transaction before injecting the new branches.

Example 1.34. t_inject_branches usage

...
route[event_notification] {
	t_inject_branches("event");
}
...


1.4.1.  notify_on_event(event, filter, route, timeout)


http://www.opensips.org/html/docs/modules/2.3.x/event_routing.html

This function creates a subscription to a given Event. A filter can be used (over the attributes of the Event) in order to filter even more the needed notifications (only Events matching the filter will be notified to this subscriber).

Upon Event notification, the given script route (usually called notification route) will be executed. No variables, SIP message, SIP transaction/dialog or any other context related to subscriber will be inherited from subscriber processing into this notification route.

The Event attributes will be exposed in the notification route via AVP variables as $avp(attr_name) = attr_value.

As an exception, in the notification route, the EBR module will make available the transaction ID from the subscriber context. Note that it's not the transaction itself, but its ID. There are some TM functions (like t_inject_branches) which can operate on transactions based on their ID. Of course, you need to have a transaction create in the subscriber processing before calling thenotify_on_event() function.

This function can be used from REQUEST_ROUTE.

Parameters:

  • event -the name of the Event to subscribe for

  • filter - a AVP variable holding (as multi value array) all the filters to be applied on the event (before notification). The filter value has the format "key=value" where the "key" must match an attribute name of the Event. The "value" is the desired value for the attribute; it may be a shell wildcard pattern. Ex: "aor=bob@*"

  • route -the name of the script route to be executed upon Event notification

  • timeout - for how long the subscription is active before expiring (integer in seconds). Note: during its lifetime, a subscription may be notified several or zero times.

Example 1.1. notify_on_event() usage

...
$avp(filter) = "aor=*@opensips.org"
notify_on_event("E_UL_AOR_INSERT","$avp(filter)","reg_done","60");
...
route[reg_done] {
	xlog("a new user $avp(aor) registered with opensips.org domain\n");
}


이 함수는 주어진 이벤트에 대한 구독을 생성합니다. 필요한 알림을 더 많이 필터링하기 위해 필터를 이벤트 속성에 사용할 수 있습니다 (필터와 일치하는 이벤트 만이 구독자에게 통보됩니다). 이벤트 통지시, 주어진 스크립트 라우트 (일반적으로 통지 라우트라고 함)가 실행됩니다. 변수, SIP 메시지, SIP 트랜잭션 / 다이얼로그 또는 가입자 관련 기타 컨텍스트는 가입자 처리에서이 통지 경로로 상속됩니다. 이벤트 속성은 $ avp (attr_name) = attr_value와 같은 AVP 변수를 통해 알림 경로에 노출됩니다. 예외 경로 인 통지 경로에서 EBR 모듈은 구독자 컨텍스트에서 트랜잭션 ID를 사용할 수 있도록합니다. 트랜잭션 자체가 아니라 ID입니다. ID를 기반으로 트랜잭션을 처리 할 수있는 몇 가지 TM 함수 (예 : t_inject_branches)가 있습니다. 물론, 당신은 thenotify_on_event () 함수를 호출하기 전에 가입자 프로세싱에서 트랜잭션 생성을 가질 필요가 있습니다. 이 함수는 REQUEST_ROUTE에서 사용할 수 있습니다. 매개 변수 : event - 구독 할 이벤트의 이름입니다. 필터 - 이벤트에 적용 할 모든 필터 (알림 전)를 다중 값 배열로 유지하는 AVP 변수입니다. 필터 값의 형식은 "key = value"이며 "key"는 이벤트의 속성 이름과 일치해야합니다. "value"는 속성에 대해 원하는 값입니다. 쉘 와일드 카드 패턴 일 수 있습니다. 예 : 'aor = bob @ *' route - 이벤트 알림시 실행할 스크립트 경로의 이름입니다. timeout - 구독이 만료되기 전에 활성화되는 시간 (초 단위의 정수)입니다. 참고 : 평생 동안 구독에 여러 번 또는 여러 번 알림이 전송 될 수 있습니다.

1.4.16.  t_wait_for_new_branches()

http://www.opensips.org/html/docs/modules/2.3.x/tm.html#t_wait_for_new_branches


This function instructs the existing SIP transaction to wait for new branches to be injected even after the completion of the existing branches. This waiting will be done until the Final Response INVITE timer (fr_inv_timeout) will hit for the transaction; of course, the waiting will be terminated if the transaction gets a 2xx final reply from one of the branches.

Normally if you have a transaction with two branches and they get, let's say, a 404 and 486 replies, the branches will be completed and transaction terminated by sending the 404 reply to the caller. Still, if you do t_wait_for_new_branches before relaying the transaction, the transaction will not terminate upon the completion of the branches and not send the 404 to the caller - it will wait for new branches to be injected (see t_inject_branches function) until the fr_inv timer hits.


이 함수는 기존 SIP 트랜잭션이 기존 브랜치가 완료된 후에도 새로운 브랜치가 삽입 될 때까지 대기하도록 지시합니다. 이 대기는 최종 응답 INVITE 타이머 (fr_inv_timeout)가 트랜잭션에 도달 할 때까지 수행됩니다. 물론 트랜잭션이 분기 중 하나에서 2xx 최종 응답을 받으면 대기가 종료됩니다.

일반적으로 두 개의 지점이있는 거래가 있고 그들이 404, 486 개의 응답을받는다면 분기가 완료되고 호출자에게 404 응답을 보내 트랜잭션이 종료됩니다. 트랜잭션을 중계하기 전에 t_wait_for_new_branches를 수행하면 트랜잭션은 분기 완료시 종료되지 않고 404를 호출자에게 보내지 않습니다. fr_inv 타이머가 히트 할 때까지 새로운 분기가 주입 될 때까지 대기합니다 (t_inject_branches 함수 참조). .


Example 1.35. t_wait_for_new_branches usage

..
t_newtran();

t_wait_for_new_branches();
t_relay(); 
조회 수 :
27117
등록일 :
2017.12.07
21:07:07 (*.160.88.18)
엮인글 :
http://webs.co.kr/index.php?document_srl=3312354&act=trackback&key=e46
게시글 주소 :
http://webs.co.kr/index.php?document_srl=3312354
List of Articles